<HEAD>
<TITLE>DeleGate reference manual version 9.9 </TITLE>
<META name=description content="DeleGate reference manual version 9.9">
<META name=keywords content="DeleGate,reference,manual">
<META http-equiv="Content-Type" content="text/html; charset=US-ASCII">

<style type="text/css">
#HtmlBody { width:800px; }
body { font-family:"courier new"; font-size:12pt; }
big { font-family:"Times New Roman"; font-size:24pt; }
#wrap { white-space:normal; }
td { white-space:nowrap; vertical-align:top; }
i { font-family:"courier new"; font-size:12pt; }
#roman { font-family:"Times New Roman"; font-size:12pt; }
pre { font-family:"courier new"; font-size:12pt; }
kbd { font-family:"courier new"; font-size:12pt; }
#hgen { text-decoration:none; }
</style>

</HEAD>

<BODY>
<DIV id=HtmlBody>
<HR>
<BIG><B>The Reference Manual of DeleGate version 9.9</B></BIG>
<BR>
<A NAME=copyright TITLE="Copyright">
<I id=roman>Copyright (c) 1994-2000 Yutaka Sato
 &lt;ysato <small>AT</small> etl.go.jp&gt;
 &lt;y <small>DOT</small> sato <small>AT</small> delegate.org&gt;</I>
<BR>
<I id=roman>Copyright (c) 1994-2000 Electrotechnical Laboratory (ETL), AIST, MITI</I>
<BR>
<I id=roman>Copyright (c) 2001-2014 National Institute of Advanced Industrial Science and Technology (AIST)</I>
<BR>
<I id=roman>AIST-Product-ID: 2000-ETL-198715-01, H14PRO-049, H15PRO-165, H18PRO-443</I>
<P>
<I id=roman>
Permission to use this material for evaluation, copy this material for
your own use, and distribute the copies via publicly accessible on-line
media, without fee, is hereby granted provided that the above copyright
notice and this permission notice appear in all copies.
<B>
AIST makes no representations about the accuracy or suitability of this
material for any purpose.  it is provided "as is", without any express
or implied warranties.
</B>
</I>
</A>
<HR>
<P id=roman>
This document is written based on the latest version of DeleGate version 9.X.
Comments about this document are expected to be directed to
<A HREF="mailto:feedback@delegate.org">mailto:feedback@delegate.org</A>
to be open and shared at
<A HREF="http://www.delegate.org/feedback/">http://www.delegate.org/feedback/</A>.
Watch <B>DeleGate Home Page</B> at
<A HREF="http://www.delegate.org/">
http://www.delegate.org/</A>
to see the latest status.
Beginners are recommended to read a short tutorial at
<A HREF="http://www.delegate.org/delegate/tutorial/">http://www.delegate.org/delegate/tutorial/</A>
also.
A collection of usage examples at
<A HREF=http://www.delegate.org/delegate/HowToDG.shtml>http://www.delegate.org/delegate/HowToDG.shtml</A> might be helpful to see what you can do with DeleGate.
A list of related documents is at
<A HREF=http://www.delegate.org/documents/>http://www.delegate.org/documents/</A>.
</P>
<HR>

<A NAME=_menu>
<DIV id=roman>
[
<A HREF=?_help>help</A>
<A HREF=http://www.delegate.org/fsx/search?index=man&sort=url>search</A>
<A HREF=?.whole>decomp</A>
<A HREF=?.parts>parts</A>
<A HREF=?.skeleton>skeleton</A>
<A HREF=${SELF}?_frames>frame</A>
]
... these links are active only when accessed via origin HTTP-DeleGate
</DIV>
</A>

<!--<nostrip/>
<A NAME=_frames TYPE=HIDDEN TITLE="Manual in Frame">
<FRAMESET COLS="10%,*" FRAMEBORDER="NO" FRAMESPACING="0" BORDER="0" NORESIZE> 
  <FRAME SRC="${SELF}?_menu_main" NAME="f-menu" MARGINWIDTH="0" MARGINHEIGHT="0" SCROLLING=no>
  <FRAME SRC="${SELF}" NAME="f-body" MARGINWIDTH="0" MARGINHEIGHT="0">
</FRAMESET>
<NOFRAME><BODY BGCOLOR="#FFFFFF"></BODY></NOFRAME>
</A>

<A NAME=_menu_main TYPE=HIDDEN TITLE="Main Menu">
<BODY BGCOLOR=#c0c0c0>
<A HREF=${SELF} TARGET=_top>no-frame</A><BR>
<A TARGET=f-body HREF=${SELF}?.skeleton>skeleton</A><BR>
<A TARGET=f-body HREF=${SELF}#pindex>p-index</A><BR>
<A TARGET=f-body HREF=${SELF}#index>index</A><BR>
<A TARGET=f-body HREF=${SELF}#NAME>name</A><BR>
<A TARGET=f-body HREF=${SELF}#SYNOPSIS>synopsis</A><BR>
<A TARGET=f-body HREF=${SELF}#DESCRIPTION>description</A><BR>
<A TARGET=f-body HREF=${SELF}#OPTIONS>options</A><BR>
<A HREF=${SELF}?_menu_param>parameters</A><BR>
<A HREF=${SELF}?_menu_example>examples</A><BR>
</BODY>
</A>

<A NAME=_menu_param TYPE=HIDDEN TITLE="Parameters">
<BODY BGCOLOR=#c0c0c0>
<A HREF=${SELF}?_menu_main>main menu</A><P>
Parameters<P>
<A TARGET=f-body HREF=${SELF}#opt_P>-P</A><BR>
<A TARGET=f-body HREF=${SELF}#opt_Q>-Q</A><BR>
<A TARGET=f-body HREF=${SELF}#opt_v>-v</A><BR>
<A TARGET=f-body HREF=${SELF}#opt_+=>+=config</A><BR>
<A TARGET=f-body HREF=${SELF}#SERVER>SERVER</A><BR>
<A TARGET=f-body HREF=${SELF}#ADMIN>ADMIN</A><BR>
<A TARGET=f-body HREF=${SELF}#CHROOT>CHROOT</A><BR>
<A TARGET=f-body HREF=${SELF}#DGROOT>DGROOT</A><BR>
<A TARGET=f-body HREF=${SELF}#PERMIT>PERMIT</A><BR>
<A TARGET=f-body HREF=${SELF}#MAXIMA>MAXIMA</A><BR>
<A TARGET=f-body HREF=${SELF}#TIMEOUT>TIMEOUT</A><BR>
<A TARGET=f-body HREF=${SELF}#MOUNT>MOUNT</A><BR>
<A TARGET=f-body HREF=${SELF}#filter-params>Filter</A><BR>
</BODY>
</A>

<A NAME=_menu_example TYPE=HIDDEN TITLE="Examples">
<BODY BGCOLOR=#c0c0c0>
<A HREF=${SELF}?_menu_main>main menu</A><P>
Examples<P>
<A TARGET=f-body HREF=${SELF}#serv_tcprelay>TCPrelay</A><BR>
<A TARGET=f-body HREF=${SELF}#serv_udprelay>UDPrelay</A><BR>
<A TARGET=f-body HREF=${SELF}#serv_FTPxHTTP>FTPxHTTP</A><BR>
<A TARGET=f-body HREF=${SELF}#serv_YYsh>YYsh</A><BR>
<A TARGET=f-body HREF=${SELF}#serv_YYMUX>YYMUX</A><BR>
<A TARGET=f-body HREF=${SELF}#serv_SockMux>SockMux</A><BR>
<A TARGET=f-body HREF=${SELF}#serv_Socks>Socks</A><BR>
<A TARGET=f-body HREF=${SELF}#serv_DGAuth>DGAuth</A><BR>
<A TARGET=f-body HREF=${SELF}#serv_PAM>PAM</A><BR>
<A TARGET=f-body HREF=${SELF}#serv_HTTP>HTTP</A><BR>
<A TARGET=f-body HREF=${SELF}#serv_ICP>ICP</A><BR>
<A TARGET=f-body HREF=${SELF}#serv_FTP>FTP</A><BR>
<A TARGET=f-body HREF=${SELF}#serv_Telnet>Telnet</A><BR>
<A TARGET=f-body HREF=${SELF}#serv_POP>POP</A><BR>
<A TARGET=f-body HREF=${SELF}#serv_IMAP>IMAP</A><BR>
<A TARGET=f-body HREF=${SELF}#serv_SMTP>SMTP</A><BR>
<A TARGET=f-body HREF=${SELF}#serv_NNTP>NNTP</A><BR>
<A TARGET=f-body HREF=${SELF}#serv_LDAP>LDAP</A><BR>
<A TARGET=f-body HREF=${SELF}#serv_Whois>Whois</A><BR>
<A TARGET=f-body HREF=${SELF}#serv_X>X</A><BR>
<A TARGET=f-body HREF=${SELF}#serv_Gopher>Gopher</A><BR>
<A TARGET=f-body HREF=${SELF}#serv_SSL>SSL</A><BR>
<A TARGET=f-body HREF=${SELF}#serv_DNS>DNS</A><BR>
<A TARGET=f-body HREF=${SELF}#serv_CU-SeeMe>CU-SeeMe</A><BR>
</A>
</BODY>
</A>

<A NAME=delegate_icon TYPE=HIDDEN CONTENT-TYPE=image/gif ENCODING=base64>
R0lGODdhIAAgAPIAAAAAAMDAwICAgP8AAAAA/////wAAAAAAACwAAAAAIAAgAAADn1hE1Q0Q
uFmipG0tdx/uFaZoHgWCJbWlFTSdrsi9FmuhJnenN/7qtdBjJxO2gp1e0ahkEouXplAqS0Z+
w9jS+dFtaVrTdRn+fgABmnmrLa9FaNbbOwyEg2wUQOA++o5nfUA9f3stc2Rxdn9zEGkNi4gf
AY8Fi4x5lZaCRQMDQI+cnZ6fL2miMqSlYKginnBoeJI6lJeYeWi2Y4iEhLw9CQA7
</A>

<nohrefgen>
ABORT
ACCEPT
ADDR
ADDRESS
AGAINST
AGENT
AF_UNIX
ALT
AND
ARCHIVE
ARTICLE
ASSOCIATE
AUTHINFO
BIND
CASE
COMMANDS
COMPOSITE
CONDITION
CONFIGDATA
CONTROL
CRYPT
CWD
DATA
DATE_GMT
DATE_LOCAL
DEFENSE
DEST
DG_PASS
DG_USER
DISABLING
DOCUMENT_NAME
DOCUMENT_URI
DOT
DST
DSTIP
END
ENCRYPTED
ENV
EPRT
EPSV
ESAC
FILE
FILTER
FQDH
FROM
GENTLE
GET
GMT
HEAD
HELLO
HELO
HIT
HIT_OBJ
HTTP_REFERER
HTTP_SERVER
HREF
HOST
IMG
INDEX
INHERIT
INTERNAL
ISSUE
LAST_MODIFIED
LINGER
LIST
LOGIN
MAIL
MAINTENANCE
META
MUST
NEGATION
NETMASK
NOT
OPERATORS
OPTION
OUTPUT
PAGE_COUNT
PAMCONF
PARAMETER
PASS
PERMUTED
PLATFORM
POST
PROTOCOL
PROXYING
PTR
PUT
RCPT
RANDENV
RECIPIENT
REFERER
REMOTE_HOST
RESOLUTION
REQUEST_URI
REQUEST_URL
SCRIPT_NAME
SD_SEND
SEE
SERVER_URL
SERVER_HOST
SIZE
SO_RCVBUF
SO_REUSEADDR
SO_REUSEPORT
SO_SEND
SO_SNDBUF
SOA
SPACE
SPECIAL
SPECIFIC
SUBSTITUTION
SWF
TAB
TIME
TYPE
TOTAL_HITS
USER
USERNAME
WILDCARD
XDC
XOVER
XXXX
YYSH
</nohrefgen>
<dohrefgen>
</dohrefgen>

-->

<P>
<A NAME=pindex TITLE="PERMUTED INDEX"><P>
PERMUTED INDEX
<UL>
<KBD>
 <A HREF="#opt_Func">-F</A>
 <A HREF="#opt_P">-P</A>
 <A HREF="#opt_P">-Q</A>
 <A HREF="#opt_f">-f</A>
 <A HREF="#opt_r">-r</A>
 <A HREF="#opt_v">-v</A>
 <A HREF="#opt_d">-d</A>
 <A HREF="#opt_D">-D</A>
 <A HREF="#ADMIN">ADMIN</A>
 <A HREF="#AF_LOCAL">AF_LOCAL</A>
 <A HREF="#aging">Aging</A>
 <A HREF="#AUTH">AUTH</A>
 <A HREF="#AUTHORIZER">AUTHORIZER</A>
 <A HREF="#BASEURL">BASEURL</A>
 <A HREF="#CACHE">CACHE</A>
 <A HREF="#CACHEFILE">CACHEFILE</A>
 <A HREF="#CAPSKEY">CAPSKEY</A>
 <A HREF="#CERTDIR">CERTDIR</A>
 <A HREF="#CGIENV">CGIENV</A>
 <A HREF="#CHARCODE">CHARCODE</A>
 <A HREF="#CHARMAP">CHARMAP</A>
 <A HREF="#CHROOT">CHROOT</A>
 <A HREF="#CLUSTER">CLUSTER</A>
 <A HREF="#CMAP">CMAP</A>
 <A HREF="#CONNECT">CONNECT</A>
 <A HREF="#COUNTER">COUNTER</A>
 <A HREF="#CRON">CRON</A>
 <A HREF="#DATAPATH">DATAPATH</A>
 <A HREF="#DELAY">DELAY</A>
 <A HREF="#DELEGATE">DELEGATE</A>
 <A HREF="#DGCONF">DGCONF</A>
 <A HREF="#DGOPTS">DGOPTS</A>
 <A HREF="#DGPATH">DGPATH</A>
 <A HREF="#DGROOT">DGROOT</A>
 <A HREF="#DGSIGN">DGSIGN</A>
 <A HREF="#DNSCONF">DNSCONF</A>
 <A HREF="#DYCONF">DYCONF</A>
 <A HREF="#DYLIB">DYLIB</A>
 <A HREF="#EXPIRE">EXPIRE</A>
 <A HREF="#FCL">FCL</A>
 <A HREF="#filter-params">FFROMCL</A>
 <A HREF="#filter-params">FFROMMD</A>
 <A HREF="#filter-params">FFROMSV</A>
 <A HREF="#filter-params">FMD</A>
 <A HREF="#filter-params">FSV</A>
 <A HREF="#filter-params">FTOMD</A>
 <A HREF="#filter-params">FTOSV</A>
 <A HREF="#FILETYPE">FILETYPE</A>
 <A HREF="#FORWARD">FORWARD</A>
 <A HREF="#FTOCL">FTOCL</A>
 <A HREF="#FTPCONF">FTPCONF</A>
 <A HREF="#HOSTLIST">HOSTLIST</A>
 <A HREF="#HOSTS">HOSTS</A>
 <A HREF="#HTMLCONV">HTMLCONV</A>
 <A HREF="#HTMUX">HTMUX</A>
 <A HREF="#HTTPCONF">HTTPCONF</A>
 <A HREF="#ICP">ICP</A>
 <A HREF="#ICPCONF">ICPCONF</A>
 <A HREF="#INETD">INETD</A>
 <A HREF="#LDPATH">LDPATH</A>
 <A HREF="#LIBPATH">LIBPATH</A>
 <A HREF="#LOGDIR">LOGDIR</A>
 <A HREF="#LOGFILE">LOGFILE</A>
 <A HREF="#MASTER">MASTER</A>
 <A HREF="#MASTERP">MASTERP</A>
 <A HREF="#MAXIMA">MAXIMA</A>
 <A HREF="#MIMECONV">MIMECONV</A>
 <A HREF="#MOUNT">MOUNT</A>
 <A HREF="#MountOptions">MountOptions</A>
 <A HREF="#MYAUTH">MYAUTH</A>
 <A HREF="#NNTPCONF">NNTPCONF</A>
 <A HREF="#OWNER">OWNER</A>
 <A HREF="#PERMIT">PERMIT</A>
 <A HREF="#PORT">PORT</A>
 <A HREF="#PROTOLOG">PROTOLOG</A>
 <A HREF="#PROXY">PROXY</A>
 <A HREF="#REACHABLE">REACHABLE</A>
 <A HREF="#REJECT">REJECT</A>
 <A HREF="#RELAY">RELAY</A>
 <A HREF="#RELIABLE">RELIABLE</A>
 <A HREF="#REMITTABLE">REMITTABLE</A>
 <A HREF="#RESOLV">RESOLV</A>
 <A HREF="#RES_AF">RES_AF</A>
 <A HREF="#RES_CONF">RES_CONF</A>
 <A HREF="#RES_DEBUG">RES_DEBUG</A>
 <A HREF="#RES_NS">RES_NS</A>
 <A HREF="#RES_RR">RES_RR</A>
 <A HREF="#RES_VRFY">RES_VRFY</A>
 <A HREF="#RES_WAIT">RES_WAIT</A>
 <A HREF="#RIDENT">RIDENT</A>
 <A HREF="#ROUTE">ROUTE</A>
 <A HREF="#RPORT">RPORT</A>
 <A HREF="#SCREEN">SCREEN</A>
 <A HREF="#SERVER">SERVER</A>
 <A HREF="#SHARE">SHARE</A>
 <A HREF="#SMTPCONF">SMTPCONF</A>
 <A HREF="#SMTPGATE">SMTPGATE</A>
 <A HREF="#serv_SockMux">SockMux</A>
 <A HREF="#SOCKOPT">SOCKOPT</A>
 <A HREF="#SOCKS">SOCKS</A>
 <A HREF="#SOCKSTAP">SOCKSTAP</A>
 <A HREF="#SOXCONF">SOXCONF</A>
 <A HREF="#SOCKMUX">SOCKMUX</A>
 <A HREF="#SRCIF">SRCIF</A>
 <A HREF="#SSLTUNNEL">SSLTUNNEL</A>
 <A HREF="#STLS">STLS</A>
 <A HREF="#SYSLOG">SYSLOG</A>
 <A HREF="#TIMEOUT">TIMEOUT</A>
 <A HREF="#TLSCONF">TLSCONF</A>
 <A HREF="#TUNNEL">TUNNEL</A>
 <A HREF="#UMASK">UMASK</A>
 <A HREF="#URICONV">URICONV</A>
 <A HREF="#VSAP">VSAP</A>
 <A HREF="#XCOM">XCOM</A>
 <A HREF="#XFIL">XFIL</A>
 <A HREF="#YYCONF">YYCONF</A>
 <A HREF="#YYMUX">YYMUX</A>
</KBD>
 <P>
<KBD>
 <A HREF="#CFIscript">CFI</A>
 <A HREF="#serv_CU-SeeMe">CU-SeeMe</A>
 <A HREF="#serv_DGAuth">DGAuth</A>
 <A HREF="#serv_DNS">DNS</A>
 <A HREF="#serv_FTP">FTP</A>
 <A HREF="#serv_Gopher">Gopher</A>
 <A HREF="#HostList">HostList</A>
 <A HREF="#serv_HTTP">HTTP</A>
 <A HREF="#serv_ICP">ICP</A>
 <A HREF="#serv_IMAP">IMAP</A>
 <A HREF="#serv_LDAP">LDAP</A>
 <A HREF="#serv_NNTP">NNTP</A>
 <A HREF="#serv_PAM">PAM</A>
 <A HREF="#serv_POP">POP</A>
 <A HREF="#ProtoList">ProtoList</A>
 <A HREF="#serv_SMTP">SMTP</A>
 <A HREF="#serv_SockMux">SockMux</A>
 <A HREF="#serv_Socks">Socks</A>
 <A HREF="#SSI.shtml">SSI.shtml</A>
 <A HREF="#serv_SSL">SSL</A>
 <A HREF="#serv_tcprelay">TCPrelay</A>
 <A HREF="#serv_Telnet">Telnet</A>
 <A HREF="#serv_udprelay">UDPrelay</A>
 <A HREF="#serv_Whois">Whois</A>
 <A HREF="#serv_FTPxHTTP">FTPxHTTP</A>
 <A HREF="#serv_X">X</A>
 <A HREF="#serv_YYsh">YYsh</A>
 <A HREF="#serv_YYMUX">YYMUX</A>
</KBD>
</UL>
</A>

<A NAME=index TITLE="INDEX"><P>
INDEX
<UL>
<DL>
<DT><A HREF="#NAME">NAME</A>
<DT><A HREF="#SYNOPSIS">SYNOPSIS</A>
<DT><A HREF="#DESCRIPTION">DESCRIPTION</A>
<DT><A HREF="#OPTIONS">OPTIONS</A> (
  <KBD>
  <A HREF="#opt_P">-P</A>
  <A HREF="#opt_P">-Q</A>
  <A HREF="#opt_f">-f</A>
  <A HREF="#opt_r">-r</A>
  <A HREF="#opt_v">-v</A>
  <A HREF="#opt_d">-d</A>
  <A HREF="#opt_D">-D</A>
  <A HREF="#opt_Func">-F</A>
  <A HREF="#opt_parameter"><I>name</I>=<I>value</I></A>
  </KBD>
  )

<DT><A HREF="#terminology">Terminology</A>
<DT><A HREF="#PARAMETERS">Parameters</A>
 <UL>
 <DL>
 <P>
 <DT><A HREF="#general">General</A><DD>
  <KBD>
  <A HREF="#SERVER">SERVER</A>
  <A HREF="#ADMIN">ADMIN</A>
  <A HREF="#OWNER">OWNER</A>
  <A HREF="#CRON">CRON</A>
  <A HREF="#INETD">INETD</A>
  <A HREF="#HOSTLIST">HOSTLIST</A>
  <A HREF="#CLUSTER">CLUSTER</A>
  <A HREF="#CMAP">CMAP</A>
  <A HREF="#DYCONF">DYCONF</A>
  <A HREF="#DYLIB">DYLIB</A>
  <A HREF="#LDPATH">LDPATH</A>
  <A HREF="#LIBPATH">LIBPATH</A>
  <A HREF="#DATAPATH">DATAPATH</A>
  <A HREF="#DGCONF">DGCONF</A>
  <A HREF="#DGPATH">DGPATH</A>
  <A HREF="#DGOPTS">DGOPTS</A>
  <A HREF="#DGSIGN">DGSIGN</A>
  <A HREF="#SOCKOPT">SOCKOPT</A>
  <A HREF="#PORT">PORT</A>
  </KBD>

 <DT><A HREF="#routing">Routing</A><DD>
  <KBD>
  <A HREF="#FORWARD">FORWARD</A>
  <A HREF="#ROUTE">ROUTE</A>
  <A HREF="#MASTER">MASTER</A>
  <A HREF="#MASTERP">MASTERP</A>
  <A HREF="#PROXY">PROXY</A>
  <A HREF="#YYMUX">YYMUX</A>
  <A HREF="#SOCKS">SOCKS</A>
  <A HREF="#SOCKSTAP">SOCKSTAP</A>
  <A HREF="#SSLTUNNEL">SSLTUNNEL</A>
  <A HREF="#VSAP">VSAP</A>
  <A HREF="#CONNECT">CONNECT</A>
  <A HREF="#SRCIF">SRCIF</A>
  <A HREF="#TUNNEL">TUNNEL</A>
  <A HREF="#RPORT">RPORT</A>
  </KBD>

 <DT><A HREF="#acl">Access control</A><DD>
  <KBD>
  <A HREF="#PERMIT">PERMIT</A>
  <A HREF="#REJECT">REJECT</A>
  <A HREF="#REMITTABLE">REMITTABLE</A>
  <A HREF="#REACHABLE">REACHABLE</A>
  <A HREF="#RELIABLE">RELIABLE</A>
  <A HREF="#SCREEN">SCREEN</A>
  <A HREF="#RELAY">RELAY</A>
  <A HREF="#AUTH">AUTH</A>
  <A HREF="#AUTHORIZER">AUTHORIZER</A>
  <A HREF="#MYAUTH">MYAUTH</A>
  <A HREF="#RIDENT">RIDENT</A>
  </KBD>

 <DT><A HREF="#resource">Resource usage restriction</A><DD>
  <KBD>
  <A HREF="#MAXIMA">MAXIMA</A>
  <A HREF="#TIMEOUT">TIMEOUT</A>
  <A HREF="#DELAY">DELAY</A>
  </KBD>

 <DT><A HREF="#caching">Cache control</A><DD>
  <KBD>
  <A HREF="#CACHE">CACHE</A>
  <A HREF="#EXPIRE">EXPIRE</A>
  <A HREF="#CACHEFILE">CACHEFILE</A>
  <A HREF="#ICP">ICP</A>
  </KBD>

 <DT><A HREF="#mounting">Mount</A><DD>
  <KBD>
  <A HREF="#MOUNT">MOUNT</A>
  <A HREF="#MountOptions">MountOptions</A>
  <A HREF="#URICONV">URICONV</A>
  <A HREF="#BASEURL">BASEURL</A>
  <A HREF="#DELEGATE">DELEGATE</A>
  </KBD>

 <DT><A HREF="#conversion">Data conversion</A><DD>
  <KBD>
  <A HREF="#CHARCODE">CHARCODE</A>
  <A HREF="#CHARMAP">CHARMAP</A>
  <A HREF="#HTMLCONV">HTMLCONV</A>
  <A HREF="#MIMECONV">MIMECONV</A>
  </KBD>

 <DT><A HREF="#filter">Filter control</A><DD>
  <KBD>
  <A HREF="#FCL">FCL</A>
  <A HREF="#FTOCL">FTOCL</A>
  <A HREF="#filter-params">FFROMCL</A>
  <A HREF="#filter-params">FSV</A>
  <A HREF="#filter-params">FTOSV</A>
  <A HREF="#filter-params">FFROMSV</A>
  <A HREF="#filter-params">FMD</A>
  <A HREF="#filter-params">FTOMD</A>
  <A HREF="#filter-params">FFROMMD</A>
  <A HREF="#XCOM">XCOM</A>
  <A HREF="#XFIL">XFIL</A>
  </KBD>

 <DT><A HREF="#localfile">Local file usage</A><DD>
  <KBD>
  <A HREF="#CHROOT">CHROOT</A>
  <A HREF="#DGROOT">DGROOT</A>
  <A HREF="#SHARE">SHARE</A>
  <A HREF="#UMASK">UMASK</A>
  <A HREF="#LOGDIR">LOGDIR</A>
  <A HREF="#LOGFILE">LOGFILE</A>
  <A HREF="#PROTOLOG">PROTOLOG</A>
  <A HREF="#COUNTER">COUNTER</A>
  <A HREF="#aging">Aging</A>
  </KBD>

 <DT><A HREF="#resolver">Host name resolution</A><DD>
  <KBD>
  <A HREF="#HOSTS">HOSTS</A>
  <A HREF="#RESOLV">RESOLV</A>
  <A HREF="#RES_CONF">RES_CONF</A>
  <A HREF="#RES_NS">RES_NS</A>
  <A HREF="#RES_AF">RES_AF</A>
  <A HREF="#RES_RR">RES_RR</A>
  <A HREF="#RES_VRFY">RES_VRFY</A>
  <A HREF="#RES_WAIT">RES_WAIT</A>
  <A HREF="#RES_DEBUG">RES_DEBUG</A>
  </KBD>

 <DT><A HREF="#protospec">Protocol specific</A><DD>
  <KBD>
  <A HREF="#HTTPCONF">HTTPCONF</A>
  <A HREF="#FILETYPE">FILETYPE</A>
  <A HREF="#CGIENV">CGIENV</A>
  <A HREF="#ICPCONF">ICPCONF</A>
  <A HREF="#FTPCONF">FTPCONF</A>
  <A HREF="#NNTPCONF">NNTPCONF</A>
  <A HREF="#SMTPCONF">SMTPCONF</A>
  <A HREF="#SMTPGATE">SMTPGATE</A>
  <A HREF="#DNSCONF">DNSCONF</A>
  </KBD>

 </DL>
 <BR>
 </UL>

<DT><A HREF="#ProtoList">ProtoList</A>
<DT><A HREF="#HostList">HostList</A>
<DT><A HREF="#Substitution">Parameter Substitution</A>
<DT><A HREF="#CFIscript">CFI and CFI Script</A>
<DT><A HREF="#DGproxy">Proxying by URL Redirection</A>

<DT><A HREF="#ProtoSpec">Protocol Specific Issue and Examples</A>
 <P>
 <UL>
  <KBD>
 <A HREF="#serv_tcprelay">TCPrelay</A>
 <A HREF="#serv_udprelay">UDPrelay</A>
 <A HREF="#serv_SockMux">SockMux</A>
 <A HREF="#serv_Socks">Socks</A>
 <A HREF="#serv_DGAuth">DGAuth</A>
 <A HREF="#serv_PAM">PAM</A>
 <A HREF="#serv_HTTP">HTTP</A>
 <A HREF="#SSI.shtml">SSI.shtml</A>
 <A HREF="#serv_ICP">ICP</A>
 <A HREF="#serv_FTP">FTP</A>
 <A HREF="#serv_Telnet">Telnet</A>
 <A HREF="#serv_POP">POP</A>
 <A HREF="#serv_IMAP">IMAP</A>
 <A HREF="#serv_SMTP">SMTP</A>
 <A HREF="#serv_NNTP">NNTP</A>
 <A HREF="#serv_LDAP">LDAP</A>
 <A HREF="#serv_Whois">Whois</A>
 <A HREF="#serv_X">X</A>
 <A HREF="#serv_Gopher">Gopher</A>
 <A HREF="#serv_SSL">SSL</A>
 <A HREF="#serv_DNS">DNS</A>
 <A HREF="#serv_CU-SeeMe">CU-SeeMe</A>
  </KBD>
 </UL>
 <BR>

<DT><A HREF="#RESERVED">Reserved Names</A>
<DT><A HREF="#AF_LOCAL">AF_LOCAL Sockets</A>
<DT><A HREF="#customize">Customization</A>
<DT><A HREF="#Platforms">Platform Specific Issue</A>
 (
 <A HREF="#Unix">Unix</A>
 <A HREF="#MSWin">MS-Windows</A>
 <A HREF="#OS2">OS/2</A>
 )

<DT><A HREF="#defense">Defense Against Attackers</A>
<DT><A HREF="#RESTART">Gentle Restart</A>
<!-- <DT><A HREF="#trouble">Trouble Shooting</A> -->
<DT><A HREF="#Functions">Functions</A>
<DT><A HREF="#FILES">FILES</A>
<DT><A HREF="#Acronyms">ACRONYMS</A>
<DT><A HREF="#SeeAlso">SEE ALSO</A>
<DT><A HREF="#Author">AUTHOR</A>
<DT><A HREF="#FEEDBACK">FEEDBACK</A>
<DT><A HREF="#DISTRIBUTION">DISTRIBUTION</A>
</DL>
</UL>
</A>

<PRE>
--------- --------- --------- --------- --------- --------- --------- ---------
DELEGATED(8)                MAINTENANCE COMMANDS                   DELEGATED(8)
</PRE>

<A NAME=NAME>
<P>
<B>NAME</B>
<UL>
delegated - DeleGate server
</UL>
</A>

<A NAME=SYNOPSIS>
<B>SYNOPSIS</B>
<UL>
<KBD>
delegated
<A HREF="#opt_P">-P<I>port</I></A>
<A HREF="#opt_f">[-f]</A>
<A HREF="#opt_r">[-r]</A>
<A HREF="#opt_Func">[-F<I>func</I>]</A>
<A HREF="#opt_v">[-v[vdts]]</A>
<A HREF="#opt_+=">[+=configfile]</A>
<A HREF="#opt_parameter">[<I>name</I>=<I>value</I>]*</A>
<A HREF="#opt_--">[--]</A>
</KBD>
</UL>
</A>

<A NAME=DESCRIPTION>
<B>DESCRIPTION</B>
<UL>
<A NAME="desc_overview" TITLE="Overview">
DeleGate is a multipurpose proxy server which relays various application 
protocols on TCP/IP or UDP/IP, including
<A HREF="#serv_HTTP">HTTP</A>,
<A HREF="#serv_FTP">FTP</A>,
<A HREF="#serv_Telnet">Telnet</A>,
<A HREF="#serv_NNTP">NNTP</A>,
<A HREF="#serv_SMTP">SMTP</A>,
<A HREF="#serv_POP">POP</A>,
<A HREF="#serv_IMAP">IMAP</A>,
<A HREF="#serv_LPR">LPR</A>,
<A HREF="#serv_LDAP">LDAP</A>,
<A HREF="#serv_ICP">ICP</A>,
<A HREF="#serv_DNS">DNS</A>,
<A HREF="#serv_SSL">SSL</A>,
<A HREF="#serv_Socks">Socks</A>,
and more.
DeleGate mediates communication between servers and clients where direct
communication is impossible, inefficient, or inconvenient.
<P>
DeleGate works as an <I>application level proxy</I> which interprets relayed
protocol (control sequence and data structure) between a client and a server;
various value added services are realized for recognized protocol.
Also DeleGate works as a <I>circuit level proxy</I> which literally conveys
transmission between a client and a server of arbitrary protocols
on <A HREF="#serv_tcprelay">TCP</A> or <A HREF="#serv_udprelay">UDP</A>.
<P>
DeleGate can be used to enforce <A HREF="#acl"><I>access control</I></A>
restricting remittable protocols,
reachable servers, and acceptable clients.
DeleGate forces delay for penalty on repetition of forbidden access,
or make <A HREF="#defense">defense</A>
shutting down service and sending automatic reports to administrator
on suspicion of attack.
A basic <A HREF="#logging"><I>logging</I></A> on circuit level
common to arbitrary protocol
and protocol dependent logging in some common formats
are supported for some protocols.
<!--
(see
<A HREF="#PERMIT">PERMIT</A>,
<A HREF="#REMITTABLE">REMITTABLE</A>,
<A HREF="#REACHABLE">REACHABLE</A>,
<A HREF="#RELIABLE">RELIABLE</A>,
<A HREF="#RELAY">RELAY</A>,
<A HREF="#DELAY">DELAY</A>)
-->
</A>

<A NAME="desc_routing" TITLE="Application Level Routing">
<P>
DeleGate can act as a kind of
<I>application level <A HREF="#routing">router</A></I>,
controlling direct or indirect routes toward a destination server
by selecting upstream proxy or Socks server.
One of exploitable routes toward a server will be selected or tried in order
depending on application protocol, destination host and source client.
<!--
(see CONNECT, MASTER, PROXY, SOCKS, ROUTE)
-->
</A>

<A NAME="desc_proxy" TITLE="Proxying, Caching and Gatewaying">
<P>
As an application level proxy, DeleGate interpretively relays
various application protocols, providing various value added services
including <A HREF="#caching"><I>caching</I></A>
or <A HREF="#conversion"><I>conversion</I></A>
for relayed data, of which structure depends on each application protocol.
Based on interpretation of application protocols,
DeleGate can be used as a <I>protocol gateway</I>
which translates between client-side protocol and server-side protocol.
<P>
As a circuit level proxy, a DeleGate server literally conveys transmission
bound to a specified server of a specified application protocol on TCP or UDP,
or toward arbitrary servers based on Socks protocol.
<!--
(see SERVER, CACHE, EXPIRE, udprelay, tcprelay)
-->
</A>

<A NAME="desc_mount" TITLE="Rewriting Resouce Identifier">
<P>
As an application level proxy, DeleGate provides virtual view for resources
in other servers, by aliasing, merging, and hiding real names
(like URL which identifies a resource or a service) in real servers.
It is like a generalized mechanism of NFS file mount,
but unlikely it is realized by rewriting content of data.
In other words, this is a mapping (rewriting)
of virtual names in client
to/from real names in server,
where names are embedded in a protocol dependent data structure
on request/response messages between a client and a server.
With this function named <A HREF="#mounting"><I>mounting</I></A>,
for example, a resource
http://hostiN/ is shown to client as if it is http://hostx/iN/.
MOUNT can be used to
<A HREF="#customize"><I>customize</I></A>
built-in icons and messages of DeleGate too.
<!--
(see MOUNT, URICONV, BASEURL, DELEGATE)
-->
</A>

<A NAME="desc_filtering" TITLE="Content Filtering">
<P>
Communication between client and DeleGate or between DeleGate and server
can be filtered or translated by user defined
<A HREF="#filter"><I>filter</I></A>
programs attached to DeleGate using a simple scheme named
<A HREF="#CFIscript">CFI</A> (Common Filter Interface).
Existing filter programs, from standard input to standard output,
can be used as a CFI program without modification.
Besides filtering by external programs,
some of frequently used filtering operations are built-in to DeleGate,
including <A HREF=#httpconf_killhead>HTTP header removal</A>
and <A HREF="#httpconf_addhead">generation</A>.
<!--
(see CHARCODE, MIMECONV, FTOCL, FFROMCL, FCL, <I>CFI-script</I>)
-->
</A>

<A NAME="desc_files" TITLE="Sharing and Aging Files">
<P>
All of <A HREF="#localfile">local files</A>
of DeleGate, including log files and cache files,
are placed under an individual root directory (<A HREF="#DGROOT">DGROOT</A>)
as private files belong to the owner of the DeleGate by default.
But to share them among different users,
the path name, owner, and access permission of each file can be customized.
Also log file name can be parameterized with date value for
<A HREF="#aging">aging</A>,
and cache file name can be parameterized with hash value to distribute
cache disks.
<!--
(CHROOT,DGROOT,LIBPATH)
-->
</A>

<A NAME="desc_mandatory" TITLE="Mandatory Options">
<P>
Although DeleGate can be controlled by a lot of options,
only <A HREF=#opt_P>-P<I>port</I></A> option and
<A HREF=#SERVER>SERVER=<I>protocol</I></A> parameter
are mandatory to operate in most case.
The -P option specifies on which <I>port</I> DeleGate receives
requests from clients. <A HREF="#SERVER">SERVER</A>
parameter specifies in which <I>protocol</I>
DeleGate communicates with clients, and optionally to which destination server
it will relay the communication.
</A>

<A NAME="opt_+=" TITLE="Configuration File"><P>
Options can be loaded from local or remote resources
with "+=<I>URL</I>" notation, 
typically from a local file like "+=/path/of/parameters"
(see <A HREF="#term_SUBSTITUTION">Parameter Substitution</A>)
(see <A HREF="#DGCONF">DGCONF</A> also)
</A>
</UL>
</A>

<A NAME=OPTIONS>
<P>
<B>OPTIONS</B>

<A NAME=entrance>
<A NAME="opt_P" TITLE="-P option">
<PRE>
   -P option  --  entrance port(s) to the DeleGate
              ==  -P<I>port</I>[,<I>port</I>]*
        <I>port</I>  ==  [<I>host</I>:]<I>portNum</I>[/udp][<A HREF=#AUTH_admin>/admin</A>][/<I>protocolName</I>]
     <I>portNum</I>  ==  <I>number</I>[-<I>number</I>]
</PRE>
<UL>
<A NAME="opt_Phostport" TITLE="-Phost:port option">
This option specifies on which <I>entrance port</I> DeleGate receives
requests from clients.
As a typical example, "-P8080" means it accepts request on TCP port
numbered 8080 on any network interface belong to the host machine.
When the host has multiple interfaces or multiple IP addresses
assigned to a single physical interface, you can select one of them
with the specification format -P<I>host</I>:<I>portNum</I>, like
"-Plocalhost:8080" for example.
A DeleGate server can accept from multiple ports or (limited) multiple
network interfaces by -P<I>port</I>,<I>port</I>,...
<BR>
When no <I>host</I> is specified, only IPv4 addresses are accepted.
That is, -P8080 is the abbreviation of "-P0.0.0.0:8080".
To specify IPv6 address here, substitute each colon symbol in the
IPv6 address notation with an under score symbol.  Fore example,
"-P__:8080" means accepting at port 8080 with the wild card address
of IPv6 "::".  If necessary, a scope-ID can be specified with "%" symbol,
like "-Pfe80__12_34%en0:8080" for example.
<BR>
Note: See <A HREF="#SRCIF">SRCIF</A>
as to selection of a source address of an outgoing connection.
</A>
<P>
An entrance port is made as a TCP port by default except UDP based
application protocol (dns, icp, cuseeme, udprelay) is specified in
SERVER=<I>protocol</I> parameter.
And regardless of the protocol specified in SERVER, it can be
made as a UDP port with postfix "/udp" like -P<I>port</I>/udp. 
<P>
If "/<I>protocolName</I>" is specified, as "-P21/ftp,80/http,1080/socks"
for example, the DeleGate will act in the specified application protocol
on the specified port, rather than in the default protocol specified in
the SERVER parameter.
<P>
This option MUST be specified except in following cases.
It is ignored when the DeleGate is invoked from <A HREF="#inetd">inetd(8)</A>,
or in most case of -F<I>function</I> option,
or when running as a <A HREF="#tunnel"><I>tunnel server</I></A>
with SERVER="tunnel1".
</UL>
</A>
<A NAME="opt_Q" TITLE="-Q option">
<PRE>
   -Q option* --  entrance port to the DeleGate
              ==  -Q<I>port</I>
</PRE>
<UL>
-Q option can be used to specify multiple entrance ports separately in
multiple options.
For example, a set of of options "-Q21 -Q80 -Q1080" is equivalent to
a single option "-P21,80,1080".
</UL>
</A>
</A>

<A NAME="opt_f" TITLE="-f option">
<PRE>
   -f option  --  foreground execution
              ==  -f[v]
</PRE><UL>
If specified, DeleGate runs in foreground keeping connected with
current control tty so that it can be killed with SIGINT from the tty,
and staying at (without changing <A HREF="#WORKDIR">work directory</A> from)
the current directory.
With -fv option, the output to the LOGFILE is also put to the console.
</UL>
</A>

<A NAME="opt_r" TITLE="-r option">
<PRE>
   -r option  --  restart
</PRE><UL>
If specified, currently running DeleGate on the same entrance port if exist
is finalized before starting this DeleGate.
It has the same effect as doing <A HREF="#func_kill">-Fkill</A> before start.
</UL>
</A>

<A NAME="opt_v" TITLE="-v option">
<PRE>
   -v option  --  logging level control
              ==  -v[vdtsau]
</PRE>
<UL>
If specified, DeleGate will run in foreground like -f and
log will be put on the control tty, not to <A HREF="#LOGFILE">LOGFILE</A>
and <A HREF="#PROTOLOG">PROTOLOG</A>.
More detailed log than that
of -v can be got using -vv option.  Similarly you can control the
detailness of log to be written into logfile by -vd, -vt or -vs options;
-vd makes logs detailed with debug information whereas
-vt makes it terse and
-vs makes logging stop and be silent;
this option has similar effect with LOGFILE="".
Another option -va makes hidden log in the most detailed level (that of -vd)
which is output only when some kind of ABORT occurred to cause
<A HREF="#defense">emergency shutout</A>.
-vu puts logging level back to usual one.
</UL>
</A>

<A NAME="opt_d" TITLE="-d option">
<PRE>
   -d option  --  debugging of sub components
              ==  -d[hst]
</PRE>
<UL>
-dh enables detailed logging of <A HREF=#HostList>HostList</A> matching.
-ds enables logging of socket manipulation including bind(), accept()
and connect().
-dt enables detailed logging of the activity of each thread with its thread-id.
</UL>
</A>

<A NAME="opt_D" TITLE="-D option">
<PRE>
   -D option  --  disabling sub components
              ==  -D[t]
</PRE>
<UL>
-Dt disables the usage of thread (for SSL and gzip) to force using process.
</UL>
</A>

<A NAME="opt_S" TITLE="-S option">
<PRE>
   -S option  --  watch SIGCHLD signal
</PRE>
<UL>
If specified, zombie processes of DeleGate will be
immediately swept by watching the SIGCHLD signal.  This option might
be the default in future releases.
</UL>
</A>

<A NAME="opt_T" TITLE="-T option">
<PRE>
   -T option  --  trace system calls
              ==  -T[xsdt]*
</PRE>
<UL>
If specified, signals occurred in DeleGate processes
will be watched by the parent DeleGate using "ptrace(2)" then recorded
into TRACELOG. If -Tx is specified, DeleGate process which is going
to execute "execve(2)" system call will be trapped and killed.  This
will be useful for security enhancement preventing any unexpected
execve() which can be the method of intruders.
This -T option automatically turn on -S option to immediately respond to
events occurred in children, but you can turn off it by adding "s"
flag like "-Ts".  Adding "d" flag like "-Txd" will make logging detailed,
while adding "t" flag like "-Txt" will make logging terse.
</UL>
</A>

<A NAME="opt_Func" TITLE="-F option">
<PRE>
   -F option  --  extra function
              ==  -F<I>function</I>
</PRE><UL>
If specified, DeleGate will work as a
program of specified <I>function</I> rather than a DeleGate server.
For example, "delegated -Fkill -P<I>port</I>" means to kill the
DeleGate running on the <I>port</I>.
"<A HREF=http://www.delegate.org/delegate/implant/>-Fimp</A>"
is a function to edit implanted parameters in the executable file
of DeleGate, to control authentication and capabilities (who can do what with
the DeleGate), and to configure fixed (not overwritable) parameters
of the executable file.
The usage is shown with "delegated -Fimp -h".
With -Fcgi, DeleGate act as a cgi program which is invoked from a HTTP server.
A list of <A HREF="#Functions">available functions</A> will be shown
with -Fhelp.
</UL>
</A>

<A NAME="opt_--" TITLE="-- option">
<PRE>
   -- option  --  hiding command line arguments
</PRE><UL>
If specified, command line arguments before "--" are left visible to
ps(1) command (with pstat(2) system call) on most of Unix systems.
Without this, any arguments are hidden by default.
</UL>
</A>

<A NAME="opt_parameter" TITLE="Parameter option">
<PRE>
   parameter  ==  <I>name</I>=<I>value</I>
</PRE><UL>
Other options are specified in <I>name</I>=<I>value</I>
format which is named a <I>parameter</I>.
Parameters can be given as environment variables as well as command line
arguments.
For <I>name</I> parameter, the environment variable DG_<I>name</I> is
retrieved prior to <I>name</I>.
Command line options with "-" prefix listed above can be given as a
parameter like DGOPTS="-P8080;-v" for example.
</UL>
</A>

<A NAME="opt_cond" TITLE="Conditional Parameter">
<PRE>
   conditional parameter == (<I>condition</I>)<I>parameter</I>
</PRE>
<UL>
Some parameters and -v option can be restricted to be applied conditionally,
by prefixing "(<I>condition</I>)" to a parameter.
Currently, <I>condition</I> is a list of client host which is described
in <A HREF="#HostList">HostList</A>.
For example, "(.localnet)-vs" specifies to suppress logging when the client
is from local networks.
Parameters which can be conditional with this prefix are:
BASEURL, DELAY, DELEGATE,
FCL, FSV, FFROMCL, FFROMSV, FTOCL, FTOSV,
LOGFILE, MAXIMA, RIDENT and TIMEOUT.
This mechanism does not work for UDP sockets.
</UL>
</A>

<A NAME="opt_-e" TITLE="-e option">
<PRE>
   -e option  ==  -e<I>name</I>=<I>value</I>
</PRE><UL>
This is similar to <I>name</I>=<I>value</I> except that
this <I>name</I>=<I>value</I> pair will be set as
an environment variable to be inherited to child processes
like filter programs and CGI programs.
</UL>
</A>
</A><!-- ---- end of OPTIONS -->

<A NAME=terminology TITLE="Terminology">
Terminology
<UL>
<DL>
<DT>delegated
<DD>A server process of DeleGate
    and the standard file name of a DeleGate program;
    the trailing "d" implies "daemon" or server (by convention on Unix)
<DT>specialist
<DD>A DeleGate configured to talk a specified client-side protocol
        (with SERVER=<I>proto</I>)
<DT>generalist
<DD>Also called MASTER-DeleGate which can talk arbitrary client-side
        protocol which will be determined at run-time
       (with SERVER="delegate") where clients are DeleGate
       which use this DeleGate as an upstream proxy
       (pointing by a MASTER parameter).
<DT>bound DeleGate
<DD>DeleGate bound to a specified destination server
        (with SERVER=<I>proto</I>://<I>host</I>)
<DT>unbound DeleGate
<DD>DeleGate not bound to any destination server
     (without SERVER=<I>proto</I>://<I>host</I>)
<DT><I>P</I>-DeleGate (ex. HTTP-DeleGate)
<DD>DeleGate communicate with clients in protocol <I>P</I>
<DT><I>Q</I>/<I>P</I>-DeleGate (ex. FTP/HTTP-DeleGate)
<DD>DeleGate communicate with clients in protocol <I>P</I>
        and communicate with servers in protocol <I>Q</I>
<DT><I>P</I> proxy (ex. HTTP proxy)
<DD>A proxy server which communicates with clients in protocol <I>P</I>
<DT><A HREF="#ProtoList">ProtoList</A>
<DD> a list of protocols
<DT><A HREF=#HostList>HostList</A>
<DD> a list of hosts or networks
<DT>dstHostList
<DD> a HostList of destination (servers)
<DT>srcHostList
<DD> a HostList of source (clients)
<DT><I>item</I>(<I>N</I>) (ex. gethostbyname(2))
<DD>reference to <I>item</I>
    described in the section <I>N</I> of Unix online manuals
</DL>
</UL>
</A>

<A NAME=PARAMETERS_CATEGORY TITLE="Parameters Category"><P>
<B>PARAMETERS</B>
<UL>
<P>
In the following list, parameters marked with "*" are
repeatable like <I>name</I>=<I>value1</I> <I>name</I>=<I>value2</I>
... <I>name</I>=<I>valueN</I>.
If the same parameter is defined both in environment and
command line, the one in command line precedes to the one in environment.
If other non-repeatable names are repeated, the lastly given value is taken.
<P>
<A NAME=extern-params TITLE="External Parameters">
Parameters marked with "+" can NOT be given in "+=<I>parameters</I>" scripts.
Those parameters (including DGROOT, CHROOT, LDPATH, and DYLIB)
need to be specified in command-line arguments
or "implanted" into the executable file of DeleGate with
the <A HREF=#opt_Func>-Fimp</A> option.
</A>
</UL>

<P>
<A NAME=general TITLE="General"><P>
General
<UL>
Parameters in this category are used to control common attributes
of DeleGate independently of the purpose of usage or
target application protocol.
<P>
<TABLE BORDER=0 CELLSPACING=0>
<TR><TD>
    <TD> name
    <TD> value format
    <TD> functionality
    <BR>
<TR><TD> --
    <TD> ----------
    <TD> ------------------
    <TD> ----------------------------------
    <BR>
<TR><TD>
    <TD> <A HREF="#SERVER"><KBD>SERVER</KBD></A>
    <TD> <I>proto</I>://<I>host</I>:<I>port</I>
    <TD>  client-side protocol and default server
    <BR>
<TR><TD>
    <TD> <A HREF="#ADMIN"><KBD>ADMIN</KBD></A>
    <TD> <I>user</I>@<I>host</I>.<I>domain</I>
    <TD> E-mail addr. of the admin. of this DeleGate
    <BR>
<TR><TD><A HREF=#extern-params>+</A>
    <TD> <A HREF="#OWNER"><KBD>OWNER</KBD></A>
    <TD> <I>user</I>[/<I>group</I>]
    <TD> with who's access right this DeleGate runs
    <BR>
<TR><TD>*
    <TD> <A HREF="#CRON"><KBD>CRON</KBD></A>
    <TD> <I>crontab-spec</I>
    <TD> <I>cron</I> compatible scheduler of actions
    <BR>
<TR><TD>*
    <TD> <A HREF="#INETD"><KBD>INETD</KBD></A>
    <TD> <I>inetd-conf</I>
    <TD> <I>inetd</I> like server configuration notation
    <BR>
<TR><TD>*
    <TD> <A HREF="#HOSTLIST"><KBD>HOSTLIST</KBD></A>
    <TD> <I>name</I>:<I>hostList</I>
    <TD> define a named <A HREF="#HostList"><I>HostList</I></A>
    <BR>
<TR><TD>*
    <TD> <A HREF="#CLUSTER"><KBD>CLUSTER</KBD></A>
    <TD> <I>protocol</I>:<I>hostList</I>
    <TD> define a cluster of servers
    <BR>
<TR><TD>*
    <TD> <A HREF="#CMAP"><KBD>CMAP</KBD></A>
    <TD> <I>map-spec</I>
    <TD> mapping table about the current connection
    <BR>
<TR><TD><A HREF=#extern-params>+</A>
    <TD> <A HREF="#DYLIB"><KBD>DYLIB</KBD></A>
    <TD> <I>patternList</I>
    <TD> file-name patterns of dynamic libraries
<TR><TD><A HREF=#extern-params>+</A>
    <TD> <A HREF="#LDPATH"><KBD>LDPATH</KBD></A>
    <TD> <I>dir</I>;<I>dir</I>;...
    <TD> search path for DYLIB
<TR><TD> 
    <TD> <A HREF="#LIBPATH"><KBD>LIBPATH</KBD></A>
    <TD> <I>dir</I>:<I>dir</I>:...
    <TD> search path for library files
<TR><TD> 
    <TD> <A HREF="#DATAPATH"><KBD>DATAPATH</KBD></A>
    <TD> <I>dir</I>:<I>dir</I>:...
    <TD> search path for data files
<TR><TD> 
    <TD> <A HREF="#DGPATH"><KBD>DGPATH</KBD></A>
    <TD> <I>dir</I>:<I>dir</I>:...
    <TD> search path for SUBSTITUTION resources
<TR><TD>*
    <TD> <A HREF="#DYCONF"><KBD>DYCONF</KBD></A>
    <TD> <I>conditions</I>:<I>path</I>
    <TD> dynamic configuration based on request
<TR><TD> 
    <TD> <A HREF="#DGCONF"><KBD>DGCONF</KBD></A>
    <TD> <I>dir</I>/<I>file</I>
    <TD> the file of configuration parameters
<TR><TD>
    <TD> <A HREF="#DGOPTS"><KBD>DGOPTS</KBD></A>
    <TD> <I>option</I>;<I>option</I>;...
    <TD> list of command line options
<TR><TD>
    <TD> <A HREF="#PORT"><KBD>PORT</KBD></A>
    <TD> <I>portList</I>
    <TD> reserve entrance ports like -P option
    <BR>
</TABLE>
</UL>
</A>

<A NAME=routing TITLE="Routing"><P>
Routing
<UL>
These parameters control the indirect routing toward the target server
exploiting upstream proxies or Socks servers on the way to servers.
If any target hosts are directly reachable on IP level from your
DeleGate's host,
these parameters may not necessary.
Besides these parameters,
<A HREF="#ICP">ICP</A> and <A HREF="#MOUNT">MOUNT</A>
have something to do with routing based on application protocols.
<P>
<TABLE BORDER=0 CELLSPACING=0>
<TR><TD> --
    <TD> ----------
    <TD> ------------------
    <TD> ----------------------------------
<TR><TD>*
    <TD> <A HREF="#FORWARD"><KBD>FORWARD</KBD></A>
    <TD> <I>proxy</I>-_-<I>proto</I>:<I>dst</I>:<I>src</I>    
    <TD> forward to <I>proxy</I> when from <I>src</I> to <I>dst</I> in <I>proto</I>
<TR><TD>*
    <TD> <A HREF="#ROUTE"><KBD>ROUTE</KBD></A>
    <TD> <I>proxy</I>-_-<I>dst</I>:<I>src</I>    
    <TD> forward to <I>proxy</I> when from <I>src</I> to <I>dst</I>
<TR><TD>*
    <TD> <A HREF="#MASTER"><KBD>MASTER</KBD></A>
    <TD> <I>host</I>:<I>port</I>
    <TD> connect via the upstream DeleGate
<TR><TD> 
    <TD> <A HREF="#MASTERP"><KBD>MASTERP</KBD></A>
    <TD> [<I>host</I>:<I>port</I>]
    <TD> invoke a MASTER private to this DeleGate
<TR><TD>*
    <TD> <A HREF="#PROXY"><KBD>PROXY</KBD></A>
    <TD> <I>host</I>:<I>port</I>
    <TD> connect via the upstream proxy
<TR><TD>*
    <TD> <A HREF="#YYMUX"><KBD>YYMUX</KBD></A>
    <TD> <I>host</I>[:<I>port</I>]
    <TD> connect via the YYMUX server
<TR><TD>*
    <TD> <A HREF="#SOCKS"><KBD>SOCKS</KBD></A>
    <TD> <I>host</I>[:<I>port</I>]
    <TD> connect via the socks server
<TR><TD> 
    <TD> <A HREF="#SSLTUNNEL"><KBD>SSLTUNNEL</KBD></A>
    <TD> <I>host</I>:<I>port</I>
    <TD> connect via the SSL tunnel for HTTPS
<TR><TD> 
    <TD> <A HREF="#VSAP"><KBD>VSAP</KBD></A>
    <TD> <I>host</I>:<I>port</I>
    <TD> accept/connect via a remote host
<TR><TD>*
    <TD> <A HREF="#CONNECT"><KBD>CONNECT</KBD></A>
    <TD> ca,ma,di,so,...
    <TD> the order of trials of connection types
<TR><TD>*
    <TD> <A HREF="#SRCIF"><KBD>SRCIF</KBD></A>
    <TD> <I>host</I>[:<I>port</I>]
    <TD> source address of connection to server
<TR><TD> 
    <TD> <A HREF="#TUNNEL"><KBD>TUNNEL</KBD></A>
    <TD> <I>type</I>:<I>scriptPath</I>
    <TD> connect via the tunnel on serial line
<TR><TD> 
    <TD> <A HREF="#RPORT"><KBD>RPORT</KBD></A>
    <TD> {tcp|udp}[:<I>host</I>]
    <TD> return port from the MASTER-DeleGate
</TABLE>
</UL>
</A>

<A NAME=acl TITLE="Access control"><P>
Access control
<UL>
These parameters control who (client) can access to what (server)
and how (protocol).
The basic policy of default access control is designed so that
clients on networks local to the host of DeleGate are permitted
to access to any server.
Note that the default value of
<A HREF="#REMITTABLE">REMITTABLE</A> depends on
<A HREF="#SERVER">SERVER</A>, and
IP-level reachability to DeleGate on a multi-homed host
may be restricted by -P<I>host</I>:<I>port</I> option.
<BR>
<B>You must most carefully configure these parameters
so that this DeleGate does not introduce a security hole,
especially when it is running on a host
which is directly accessible to/from the internet.</B>
<P>
<TABLE BORDER=0 CELLSPACING=0>
<TR><TD> --
    <TD> ----------
    <TD> ------------------
    <TD> ----------------------------------
<TR><TD>*
    <TD> <A HREF="#PERMIT"><KBD>PERMIT</KBD></A>
    <TD> <I>proto</I>:<I>dst</I>:<I>src</I>
    <TD> protocols/servers/clients to be permitted
<TR><TD>*
    <TD> <A HREF="#REJECT"><KBD>REJECT</KBD></A>
    <TD> <I>proto</I>:<I>dst</I>:<I>src</I>
    <TD> protocols/servers/clients to be rejected
<TR><TD> 
    <TD> <A HREF="#REMITTABLE"><KBD>REMITTABLE</KBD></A>
    <TD> <I>ProtoList</I>
    <TD> protocols remittable to the server
<TR><TD>*
    <TD> <A HREF="#REACHABLE"><KBD>REACHABLE</KBD></A>
    <TD> <I>dstHostList</I>
    <TD> only specified server hosts are reachable
<TR><TD>*
    <TD> <A HREF="#RELIABLE"><KBD>RELIABLE</KBD></A>
    <TD> <I>srcHostList</I>
    <TD> accept only from the specified client hosts
<TR><TD>*
    <TD> <A HREF="#SCREEN"><KBD>SCREEN</KBD></A>
    <TD> <I>{reject|accept}</I>
    <TD> screen client host
<TR><TD>*
    <TD> <A HREF="#RELAY"><KBD>RELAY</KBD></A>
    <TD> proxy|delegate|no
    <TD> restrict proxying modes
<TR><TD>*
    <TD> <A HREF="#AUTH"><KBD>AUTH</KBD></A>
    <TD> <I>what</I>:<I>aproto</I>:<I>users</I>
    <TD> authorized users for remote administration
<TR><TD>*
    <TD> <A HREF="#AUTHORIZER"><KBD>AUTHORIZER</KBD></A>
    <TD> <I>serv</I>:<I>proto</I>:<I>dst</I>:<I>src</I>
    <TD> authentication server
<TR><TD>*
    <TD> <A HREF="#MYAUTH"><KBD>MYAUTH</KBD></A>
    <TD> <I>user</I>:<I>pass</I>:<I>proto</I>:<I>dst</I>:<I>src</I>
    <TD> authentication client
<TR><TD> 
    <TD> <A HREF="#RIDENT"><KBD>RIDENT</KBD></A>
    <TD> client|server
    <TD> forward socket addr. to upstream DeleGate
</TABLE>
</UL>
</A>

<A NAME=resource TITLE="Resource usage restriction"><P>
Resource usage restriction
<UL>
These parameters can be useful where available resources are
in severe condition; when the host of DeleGate is heavy loaded,
network bandwidth is narrow, or response from server can be slow.
<P>
<TABLE BORDER=0 CELLSPACING=0>
<TR><TD> --
    <TD> ----------
    <TD> ------------------
    <TD> ----------------------------------
<TR><TD>*
    <TD> <A HREF="#MAXIMA"><KBD>MAXIMA</KBD></A>
    <TD> <I>what</I>:<I>number</I>
    <TD> maxima of parallel sessions and etc.
<TR><TD>*
    <TD> <A HREF="#TIMEOUT"><KBD>TIMEOUT</KBD></A>
    <TD> <I>what</I>:<I>seconds</I>
    <TD> timeout of connection and etc.
<TR><TD>*
    <TD> <A HREF="#DELAY"><KBD>DELAY</KBD></A>
    <TD> <I>what</I>:<I>seconds</I>
    <TD> delay for penalty
</TABLE>
</UL>
</A>

<A NAME=caching TITLE="Cache control"><P>
Cache control
<UL>
Enable or disable cache and specify validity of cached data.
Usage of cache is controlled in context of routing by
<A HREF="#CONNECT">CONNECT</A> too.
Removing stale cache file can be done periodically using
<A HREF="#CRON">CRON</A>.
<P>
<TABLE BORDER=0 CELLSPACING=0>
<TR><TD> --
    <TD> ----------
    <TD> ------------------
    <TD> ----------------------------------
<TR><TD>
    <TD> <A HREF="#CACHE"><KBD>CACHE</KBD></A>
    <TD> do|no|ro
    <TD> control to do cache or not
<TR><TD>*
    <TD> <A HREF="#EXPIRE"><KBD>EXPIRE</KBD></A>
    <TD> <I>days</I>|<I>hours</I>|<I>secs</I>
    <TD> expiration of the cached data
<TR><TD> 
    <TD> <A HREF="#CACHEFILE"><KBD>CACHEFILE</KBD></A>
    <TD> <I>fileNameSpec</I>
    <TD> in which file cache data are stored
<TR><TD>*
    <TD> <A HREF="#ICP"><KBD>ICP</KBD></A>
    <TD> <I>icpClientConfig</I>
    <TD> configuration as an ICP client
</TABLE>
</UL>
</A>

<A NAME=mounting TITLE="Mount"><P>
Mount
<UL>
Provide virtual view for other server(s) by URL mapping,
filtering and aliasing resource names,
to merge multiple servers,
to translate between different protocols,
to export internal servers,
and so on.
Also MOUNT can be used to <A HREF="#customize">customize</A>
or replace built-in icons and messages.
<P>
<TABLE BORDER=0 CELLSPACING=0>
<TR><TD> --
    <TD> ----------
    <TD> ------------------
    <TD> ----------------------------------
<TR><TD>*
    <TD> <A HREF="#MOUNT"><KBD>MOUNT</KBD></A>
    <TD> "<I>vURL<I> <I>rURL<I> <I>opt<I>"
    <TD> map virtual <I>URL</I> to/from real <I>URL</I>
<TR><TD>*
    <TD> <A HREF="#URICONV"><KBD>URICONV</KBD></A>
    <TD> <I>convList</I>:<I>attrList</I>
    <TD> control URI rewriting with MOUNT
<TR><TD>
    <TD> <A HREF="#BASEURL"><KBD>BASEURL</KBD></A>
    <TD> <I>URL</I>
    <TD> the base of (virtual) URL of this server
<TR><TD>
    <TD> <A HREF="#DELEGATE"><KBD>DELEGATE</KBD></A>
    <TD> <I>host</I>:<I>port</I>
    <TD> limited form of BASEURL
</TABLE>
</UL>
</A>

<A NAME=conversion TITLE="Data conversion"><P>
Data conversion
<UL>
Parameters to control built-in converter for text type data.
<P>
<TABLE BORDER=0 CELLSPACING=0>
<TR><TD> --
    <TD> ----------
    <TD> ------------------
    <TD> ----------------------------------
<TR><TD>*
    <TD> <A HREF="#CHARCODE"><KBD>CHARCODE</KBD></A>
    <TD> JIS|EUC|SJIS|UTF8
    <TD> character conversion for Japanese text
<TR><TD>*
    <TD> <A HREF="#CHARMAP"><KBD>CHARMAP</KBD></A>
    <TD> [jis|ucs]:a-z/A-Z
    <TD> map character to character in text data
<TR><TD> 
    <TD> <A HREF="#HTMLCONV"><KBD>HTMLCONV</KBD></A>
    <TD> deent|enent|pre
    <TD> decode/encode between HTML & plain text
<TR><TD> 
    <TD> <A HREF="#MIMECONV"><KBD>MIMECONV</KBD></A>
    <TD> thru|charcode
    <TD> control MIME encoder/decoder
</TABLE>
</UL>
</A>

<A NAME=filter TITLE="Filter control"><P>
Filter control
<UL>
Insert a filter program on the way to/from client or server
to convert data transmitted between them.
<P>
<TABLE BORDER=0 CELLSPACING=0>
<TR><TD> --
    <TD> ----------
    <TD> ------------------
    <TD> ----------------------------------
<TR><TD> 
    <TD> <A HREF="#FCL"><KBD>FCL</KBD></A>
    <TD> <I>filterCommand</I>
    <TD> filter between client and DeleGate
<TR><TD> 
    <TD> <KBD>FTOCL</KBD>
    <TD> <I>filterCommand</I>
    <TD> filter from DeleGate to client
<TR><TD> 
    <TD> <KBD>FFROMCL</KBD>
    <TD> <I>filterCommand</I>
    <TD> filter from client to DeleGate
<TR><TD> 
    <TD> <KBD>FSV</KBD>
    <TD> <I>filterCommand</I>
    <TD> filter between server and DeleGate
<TR><TD> 
    <TD> <KBD>FTOSV</KBD>
    <TD> <I>filterCommand</I>
    <TD> filter from DeleGate to server
<TR><TD> 
    <TD> <KBD>FFROMSV</KBD>
    <TD> <I>filterCommand</I>
    <TD> filter from server to DeleGate
<TR><TD> 
    <TD> <KBD>FMD</KBD>
    <TD> <I>filterCommand</I>
    <TD> filter between MASTER and this DeleGate
<TR><TD> 
    <TD> <KBD>FTOMD</KBD>
    <TD> <I>filterCommand</I>
    <TD> filter from this DeleGate to MASTER
<TR><TD> 
    <TD> <KBD>FFROMMD</KBD>
    <TD> <I>filterCommand</I>
    <TD> filter from MASTER to this DeleGate
<TR><TD> 
    <TD> <A HREF="#XCOM"><KBD>XCOM</KBD></A>
    <TD> <I>filterCommand</I>
    <TD> execute a command as a server
<TR><TD> 
    <TD> <KBD>XFIL</KBD>
    <TD> <I>filterCommand</I>
    <TD> execute a filter as a server
</TABLE>
</UL>
</A>

<A NAME=localfile TITLE="Local file usage"><P>
Local file usage
<A NAME=logging TITLE="Logging">
<UL>
All of local files are integrated under DGROOT by default.
You should not change nor specify these parameters if not necessary.
<P>
<TABLE BORDER=0 CELLSPACING=0>
<TR><TD> --
    <TD> ----------
    <TD> ------------------
    <TD> ----------------------------------
<TR><TD><A HREF=#extern-params>+</A>
    <TD> <A HREF="#CHROOT"><KBD>CHROOT</KBD></A>
    <TD> <I>dirPath</I>
    <TD> change the root of file system at start
<TR><TD><A HREF=#extern-params>+</A>
    <TD> <A HREF="#DGROOT"><KBD>DGROOT</KBD></A>
    <TD> <I>dirPath</I>
    <TD> root directory of all of DeleGate files
<TR><TD>*<A HREF=#extern-params>+</A>
    <TD> <A HREF="#SHARE"><KBD>SHARE</KBD></A>
    <TD> <I>dirPatternList</I>
    <TD> files to be shared among users
<TR><TD><A HREF=#extern-params>+</A>
    <TD> <A HREF="#UMASK"><KBD>UMASK</KBD></A>
    <TD> <I>mask</I>
    <TD> umask value in octal
<TR><TD> 
    <TD> <A HREF="#VARDIR"><KBD>VARDIR</KBD></A>
    <TD> <I>dirPath</I>
    <TD> default base of log and cache
<TR><TD> 
    <TD> <A HREF="#CACHEDIR"><KBD>CACHEDIR</KBD></A>
    <TD> <I>dirPath</I>
    <TD> where cache files are placed
<TR><TD> 
    <TD> <A HREF="#ADMDIR"><KBD>ADMDIR</KBD></A>
    <TD> <I>dirPath</I>
    <TD> where dynamic administration files are
<TR><TD> 
    <TD> <A HREF="#ETCDIR"><KBD>ETCDIR</KBD></A>
    <TD> <I>dirPath</I>
    <TD> where persistent management files are
<TR><TD> 
    <TD> <A HREF="#LOGDIR"><KBD>LOGDIR</KBD></A>
    <TD> <I>dirPath</I>
    <TD> where DeleGate logs are
<TR><TD> 
    <TD> <KBD>LOGFILE</KBD>
    <TD> <I>LogFilename</I>
    <TD> where DeleGate makes logging
<TR><TD> 
    <TD> <KBD>PROTOLOG</KBD>
    <TD> <I>LogFilename</I>
    <TD> httpd or wu-ftp compatible log file
<TR><TD> 
    <TD> <KBD>ERRORLOG</KBD>
    <TD> <I>LogFilename</I>
    <TD> where DeleGate make error logging
<TR><TD> 
    <TD> <KBD>TRACELOG</KBD>
    <TD> <I>LogFilename</I>
    <TD> where signal trace (by -T) is put
<TR><TD> 
    <TD> <KBD>EXPIRELOG</KBD>
    <TD> <I>LogFilename</I>
    <TD> file which records expire log
<TR><TD> 
    <TD> <KBD>WORKDIR</KBD>
    <TD> <I>dirPath</I>
    <TD> where DeleGate should dump core (-_-;
<TR><TD> 
    <TD> <KBD>ACTDIR</KBD>
    <TD> <I>dirPath</I>
    <TD> where temporary files are placed
<TR><TD> 
    <TD> <KBD>TMPDIR</KBD>
    <TD> <I>dirPath</I>
    <TD> where invisible temporary files are placed
<TR><TD> 
    <TD> <KBD>PIDFILE</KBD>
    <TD> <I>fileName</I>
    <TD> where the DeleGate's PID is recorded
<TR><TD> 
    <TD> <A HREF="#COUNTER"><KBD>COUNTER</KBD></A>
    <TD> <I>CounterOptions</I>
    <TD> access counters
</TABLE>
</UL>
</A>
</A>

<A NAME=resolver TITLE="Host name resolution"><P>
Host name resolution
<UL>
Resolve host name to/from IP address using DNS, NIS or local file.
<P>
<TABLE BORDER=0 CELLSPACING=0>
<TR><TD> --
    <TD> ----------
    <TD> ------------------
    <TD> ----------------------------------
<TR><TD>*
    <TD> <A HREF=#HOSTS><KBD>HOSTS</KBD></A>
    <TD> <I>host</I>/<I>addr</I>,...
    <TD> private host/address mapping
<TR><TD>
    <TD> <A HREF=#RESOLV><KBD>RESOLV</KBD></A>
    <TD> file,nis,dns,sys
    <TD> the order of resolvers to be used
<TR><TD>
    <TD> <A HREF=#RES_WAIT><KBD>RES_WAIT</KBD></A>
    <TD> sec:host
    <TD> wait for resolver to be ready
<TR><TD>
    <TD> <A HREF=#RES_CONF><KBD>RES_CONF</KBD></A>
    <TD> <I>URL</I>
    <TD> where <I>resolv.conf</I> is
<TR><TD>
    <TD> <A HREF=#RES_NS><KBD>RES_NS</KBD></A>
    <TD> <I>host</I>[:<I>port</I>]
    <TD> DNS server to be used
<TR><TD>
    <TD> <A HREF=#RES_AF><KBD>RES_AF</KBD></A>
    <TD> 46 | 64 | 4 | 6
    <TD> Address families (IPv4/v6) to be retrieved
<TR><TD>
    <TD> <A HREF=#RES_RR><KBD>RES_RR</KBD></A>
    <TD> <I>HostList</I>
    <TD> enable Round Robin of IP-addresses
<TR><TD>
    <TD> <A HREF=#RES_VRFY><KBD>RES_VRFY</KBD></A>
    <TD> ""
    <TD> enable double check of reverse resolution
<TR><TD>
    <TD> <A HREF=#RES_DEBUG><KBD>RES_DEBUG</KBD></A>
    <TD> <I>number</I>
    <TD> debugging level of name resolution
</TABLE>
</UL>
</A>

<A NAME=protospec TITLE="Protocol specific">
Protocol specific
<UL>
<TABLE BORDER=0 CELLSPACING=0>
<TR><TD> --
    <TD> ----------
    <TD> ------------------
    <TD> ----------------------------------
<TR><TD>*
    <TD> <A HREF="#HTTPCONF"><KBD>HTTPCONF</KBD></A>
    <TD> <I>what</I>:<I>conf</I>
    <TD> HTTP specific configuration
<TR><TD> 
    <TD> <A HREF="#FILETYPE"><KBD>FILETYPE</KBD></A>
    <TD> <I>suffix<I>:<I>fileType</I>
    <TD> mapping from filename to data type & etc.
<TR><TD> 
    <TD> <A HREF="#CGIENV"><KBD>CGIENV</KBD></A>
    <TD> <I>name</I>,<I>name</I>,...
    <TD> environment variables to be passed to CGI
<TR><TD>*
    <TD> <A HREF="#ICPCONF"><KBD>ICPCONF</KBD></A>
    <TD> <I>icpServerConfig</I>
    <TD> configuration as an ICP server
<TR><TD>*
    <TD> <A HREF="#FTPCONF"><KBD>FTPCONF</KBD></A>
    <TD> <I>what</I>[:<I>conf</I>]
    <TD> FTP specific configuration
<TR><TD>*
    <TD> <A HREF="#NNTPCONF"><KBD>NNTPCONF</KBD></A>
    <TD> <I>what</I>:<I>conf</I>
    <TD> NNTP specific configuration
<TR><TD>* 
    <TD> <A HREF="#SMTPCONF"><KBD>SMTPCONF</KBD></A>
    <TD> <I>what</I>:<I>conf</I>
    <TD> SMTP specific configuration
<TR><TD> 
    <TD> <A HREF="#SMTPGATE"><KBD>SMTPGATE</KBD></A>
    <TD> <I>dirPath</I>
    <TD> SMTP to SMTP/NNTP g.w. configuration
<TR><TD>*
    <TD> <A HREF="#DNSCONF"><KBD>DNSCONF</KBD></A>
    <TD> <I>what</I>:<I>conf</I>
    <TD> configuration as a DNS server
<TR><TD>*
    <TD> <A HREF="#SOCKSTAP"><KBD>SOCKSTAP</KBD></A>
    <TD> <I>proto</I>[:[<I>dst</I>][:<I>src</I>]]
    <TD> interpret the protocol over SOCKS
</TABLE>
</UL>
</A>
</A>

<A NAME=PARAMETERS>
<A NAME="SERVER">
<PRE>
SERVER parameter*   ==  SERVER=<I>protocol</I>[://<I>host</I>[:<I>portNum</I>]][:-:<I>MountOptions</I>]
           <I>portNum</I>  ==  [+|-]<I>number</I>
                    --  default: SERVER=delegate
</PRE>
<UL>
SERVER=<I>protocol</I>
specifies the protocol to be used for communication with clients,
which will be the default protocol with servers.
<P>
Example: a SERVER parameter for unbound Telnet-DeleGate
<UL>
<KBD>SERVER=telnet</KBD>
</UL>
</P>
If SERVER="delegate" is given, the DeleGate will become a
<I>generalist</I> (or MASTER-DeleGate),
which acts as an upstream DeleGate of other DeleGates.
<B>Note that a <I>generalist</I> can remit arbitrary protocols by default,
so that it can be dangerous
without enough consideration on access control
</B>
(see <A HREF="#REMITTABLE">REMITTABLE</A>).
A generalist automatically detects multiple protocol,
including HTTP, proxy-Whois,
as well as DeleGate original protocol.
<P>
If no destination server (<I>host</I>) is specified,
it is to be be given by client somehow at run-time,
on application level in protocol dependent way.
<P>
<UL>
Several protocols including "http" and "socks" have inherent and automatic way
to do proxying.  Some protocols, like "ftp" and "pop", with a subprotocol to
<I>login</I> to server are naturally extended so that information about
destination server is encoded as <I>user</I>@<I>host</I> for <I>user name</I>
as login information.
Some protocols, including "whois" and "gopher", in which the first message is
sent from client side, typically as a query message,
the message is extended (without changing the specification)
to include information about destination server.
Some of other protocols like "telnet" have interaction with user on a client
program thus can be extended with login dialogue for proxying.
</UL>
<P>
The protocol with server is implicitly expected to be the same with the
protocol with the client.
Some protocols like HTTP have their inherent way to specify the protocol with
the destination server.
Otherwise it must be explicitly given with MOUNT parameter, like
MOUNT="/news/* nntp://server/*" for example.
<P>
SERVER=<I>protocol</I>://<I>host</I>:<I>portNum</I> specifies the URL of
destination server.
The ":<I>portNum</I>" part is omittable as usual in URL
if the number is that of standard port number of the <I>protocol</I>.
A list of protocols and standard port numbers recognized by
the DeleGate is available at:
"http://<I>delegate</I>/-/builtin/mssgs/config.dhtml".

<A NAME=portmap TITLE="port mapping">
<P>
Port mapping:
If a <I>portNum</I> is prefixed with "-" or "+",
it means mapping the port number of the <A HREF="#entrance">entrance</A> port
adding the specified offset,
or using the port number as is by "-" with empty <I>portNum</I>.
<P>
Example: forwarding multiple ports to an another host<UL>
<KBD>
-P21,23,25,80 SERVER=tcprelay://<I>host</I>:-/
</KBD>
</UL>

<P>
A special hostname <A HREF="#odst.-">"<KBD>odst.-</KBD>"</A> can be used
to refer the original destination host when the incoming data is
forwarded by NAT.
<P>
Example: forwarding NAT to the original destination via a SOCKS proxy<UL>
<KBD>
-P9999 SERVER=tcprelay://odst.-:- SOCKS=sockshost
</KBD>
</UL>
</A>

<B>
<P>
Note that a DeleGate bound to a specific server is not disabled to
work as a proxy for arbitrary servers.
Proxying ability must be restricted if necessary, using
PERMIT, REACHABLE and RELAY parameters.
</B>

<A NAME=SERVER_mount TITLE="conditional SERVER">
<P>
If a SERVER parameter is with ":-:<I>MountOptions</I>",
the SERVER parameter will be dynamically selected if the condition
specified in the <A HREF="#MountOptions">MountOptions</A>
is evaluated to be true.
As a special case, ":-:via=<I>HostList</I>" can be abbreviated
as ":-:<I>HostList</I>".
<P>
Example: selecting an appropriate NNTP server for a client
<UL>
<KBD>
SERVER="nntp://<I>newsserver1</I>:-:from={*.<I>dom1</I>}"<BR>
SERVER="nntp://<I>newsserver2</I>:-:from={*.<I>dom2</I>}"
</KBD>
</UL>
<P>
Example: {NNTP,SMTP,POP}-DeleGate as a single server
<UL>
<KBD>
-P119,110,25<BR>
SERVER="nntp://nntpserver:-:{*:119}"<BR>
SERVER="smtp://smtpserver:-:{*:25}"<BR>
SERVER="pop://popserver:-:{*:110}"<BR>
</KBD>
</UL>
</A>

</UL>
</A>

<A NAME=ADMIN>
<PRE>
ADMIN parameter     ==  ADMIN=<I>user</I>@<I>host</I>.<I>domain</I>
                    --  default: <I>built in at compile time</I>
</PRE>
<UL>
This parameter must be correctly given especially when the DeleGate runs on
a host directly reachable to/from internet.
This E-mail address will be used as follows:
<P>
<TABLE BORDER=0 CELLSPACING=0>
<TR><TD> - <TD id=wrap>Shown in (error) messages to clients, as the name of
           the administrator of this DeleGate
           (HTTP, etc.).<BR>
<TR><TD> - <TD id=wrap>Shown in opening messages or in a help message to clients,
           as the name of the administrator (FTP, NNTP, Telnet).<BR>
<TR><TD> - <TD id=wrap>Sent as a default user name (in PASS command)
           on anonymous access to FTP servers.<BR>
<TR><TD> - <TD id=wrap>Sent as sender name (in FROM command)
           in access to remote SMTP server on verification
           by AUTH=<A HREF="#smtp-vrfy">anonftp:smtp-vrfy</A>.<BR>
<TR><TD> - <TD id=wrap>Report messages are sent to the address
           on occurrence of fatal signals
</TABLE>
</UL>
</A>


<A NAME=OWNER>
<PRE>
OWNER parameter*    ==  OWNER=<I>user</I>[/<I>group</I>][:<I>srcHostList</I>]
                    --  default: OWNER="nobody/nogroup"
                    --  restriction: super-user only on most of Unix
                    --  restriction: setting the user of a service on Windows
</PRE>
<UL>
This parameter is effective only when the invoker is a super-user.
If specified, the DeleGate will run with the right of specified
user, calling setuid(2) and setgid(2) system calls. User and group
can be specified either in symbolic name or in id-number prefixed
with "#" like "#1234".
<BR>
If <I>srcHostList</I> is specified, owner of this DeleGate will be set to
the user when the client host is included in the list.  The user
name "*" will be substituted by the user name of the client when
it can be got from an
<A HREF="#Ident">Identification</A> server on the client host.
<P>
Example:
run with the user ID corresponding to the user name of the client
<UL>
<KBD>
OWNER="*:*@*".
</KBD>
</UL>
<P>
On Windows, <KBD>OWNER=</KBD><I>user</I> may be specified when it is
invoked as a service, to set the user of the DeleGate service to be created.
With empty user name as <KBD>OWNER=""</KBD>, the user name is got from
the <KBD>USERNAME</KBD> environment variable.  The password can be specified
with a <KBD>PASS=</KBD><I>pass</I> parameter or an environment variable, or
it will be asked on the console.
</UL>
</A>

<A NAME=CRON>
<PRE>
CRON parameter*     ==  CRON="<I>crontab-spec</I>"
       <I>crontab-spec</I> ==  <I>minute</I> <I>hour</I> <I>day</I> <I>month</I> <I>dayOfWeek</I> <I>action</I>
                    --  default: none
</PRE>
<UL>
Cause an action at a time specified in the format of <I>crontab-spec</I>
which is compatible with that of standard crontab(5) of <I>cron</I>(8)
servers in Unix systems.
If the action is prefixed with "/" then it is an external action
which will be executed by the system(3) function.  If the action is
prefixed with "-" then it is a built-in internal action of DeleGate.
<P>
<A NAME=act_restart TITLE="-restart action">
<TABLE BORDER=0 CELLSPACING=0>
<TR><TD><KBD>-suspend <I>N</I></KBD><TD> -- suspend for <I>N</I> seconds
<TR><TD><KBD>-restart         </KBD><TD> -- <A HREF="#RESTART">restart</A> the DeleGate
<TR><TD><KBD>-exit            </KBD><TD> -- finish the DeleGate
<TR><TD><KBD>-expire <I>N</I> </KBD><TD> -- execute expiration for $CACHEDIR
                                 by "-atime +<I>N</I>d"
<TR><TD><KBD>-system <I>command</I></KBD><TD>
-- execute <I>command</I> as a shell command
<TR><TD><KBD><I>/dir/command</I> <I>args</I></KBD><TD>
-- equiv. to "-system <I>/dir/command</I> <I>args</I>"
<TR><TD><KBD>- <I>args</I>            </KBD><TD>
-- equiv. to "<I>/dir</I>/delegated <I>args</I>"
<TR><TD><KBD>-F<I>func</I> <I>args</I></KBD><TD>
-- equiv. to "<I>/dir</I>/delegated -F<I>func</I> <I>args</I>"
</TABLE>
<P>
Example:
<UL>
<KBD>
CRON="0 0 * * * -restart"<BR>
CRON="0 3 * * * -expire 3"  (this is equivalent to followings)<BR>
CRON="0 3 * * * -Fexpire /path/of/cache -rm -atime +3 -sum"<BR>
CRON="0 3 * * * /path/of/delegated -Fexpire /path/of/cache -rm -atime +3 -sum"<BR>
</KBD>
</UL>
</A>
</UL>
</A>

<A NAME=INETD>
<PRE>
INETD parameter*    ==  INETD="<I>inetd-conf</I>"
        <I>inetd-conf</I>  ==  <I>port</I> <I>sockType</I> <I>proto</I> <I>waitStat</I> <I>uid</I> <I>execPath</I> <I>argList</I>
              <I>port</I>  ==  [<I>host</I>:]<I>portNum</I>
          <I>sockType</I>  ==  stream | dgram
             <I>proto</I>  ==  tcp | udp
          <I>waitStat</I>  ==  nowait ("wait" is not yet supported)
                    --  default: none
</PRE>
<UL>
Invoke a new DeleGate process with the specified configuration when
a request is arrived at the specified port.  The format of the
<I>inetd-conf</I> specification is like that of standard inetd.conf(5)
in Unix systems.<BR>

A default value of each field can be represented by "-".
Default values of <I>sockType</I>, <I>proto</I> and <I>waitStat</I>
are "stream", "tcp" and "nowait" respectively.
The <I>uid</I> field will be used as
<A HREF="#OWNER">OWNER</A> parameter in the invoked process.
Specifying "-" as <I>uid</I> value means
invoking DeleGate without OWNER parameter.

If <I>execPath</I> is "-",
it means to start child DeleGate process with the given <I>argList.</I>
The configuration of the parent DeleGate process is inherited to
child DeleGates.  For example, when a parent DeleGate is invoked
like:
<UL>
<KBD>
delegated ADMIN=foo EXPIRE=1 INETD=<I>conf1</I> INETD=<I>conf2</I>
</KBD>
</UL>
these ADMIN and EXPIRE parameters are inherited to DeleGates
described in <I>conf1</I> and <I>conf2</I>.
<P>        
Example:
<KBD>
<UL>
    INETD="8080 stream tcp nowait nobody - SERVER=http"
<BR>INETD="8080 - - - nobody - SERVER=http" (equivalent to the above)
<BR>INETD="8119 - - - - - SERVER=nntp://nntpserver/"
<BR>INETD="8888 - - - - /bin/date date" (equivalent to the following)
<BR>INETD="8888 - - - - - SERVER=exec XCOM="/bin/date date"'
<BR>INETD="8888 dgram  udp - - /bin/date date"
<BR>INETD="localhost:8888 - - - - - /bin/sh sh"
<BR>INETD=+=/path/of/inetd.conf  (load configuration from a file)
</UL>
</KBD>
</UL>
</A>

<A NAME=HOSTLIST>
<PRE>
HOSTLIST parameter* ==  HOSTLIST=<I>listName</I>:<I>HostList</I>
</PRE>
<UL>
Define a named <A HREF="#HostList"><I>HostList</I></A> with the name <I>listName</I>.
A named HostList can be referred in other HostLists.
If multiple HOSTLIST parameters with the same <I>listName</I> are defined,
the lastly defined one is referred.
If a <I>HostList</I> is prefixed with "+,"
like HOSTLIST="<I>listName</I>:+,<I>newHostList</I>"
then the <I>newHostList</I> is appended to the current definition of the list.
<P>
<A NAME=HOSTLIST_predef TITLE="Predefined named HostList">
Predefined named HostList:
<UL>
<DL>
<DT>HOSTLIST=<KBD><A HREF="#localnet">.localnet</A>:localhost,./.,-/.,.o/."</KBD>
<DD>
<DT>HOSTLIST=<KBD><A HREF="#SOCKS">.socksdst</A>:!.localnet</KBD>
<DD>
</DL>
</UL>
</A>
<P>
Example:
<KBD>
<UL>
    // redefine .localnet
<BR>HOSTLIST=".localnet:localhost,./32,192.168.*"
<BR>// exclude localhost form the predefined .localnet
<BR>HOSTLIST=".localnet:+,!localhost"
</UL>
</KBD>
</UL>
</A>

<A NAME=CLUSTER>
<PRE>
CLUSTER parameter*  ==  CLUSTER=[<I>protoList</I>]:<I>ServerList</I>
        <I>ServerList</I>  ==  [/R,]<I>Server</I>[,<I>ServerList</I>]
            <I>Server</I>  ==  <I>Host</I>[..<I>Port</I>]
</PRE>
<UL>
The <KBD>CLUSTER</KBD> parameter defines an ordered set of alternative or
complemental servers (origin or proxy).
It is referred when DeleGate failed to connect or authenticate with
an upstream proxy server or an origin server.
It is applied to proxy server specified in
<KBD>MASTER</KBD>, <KBD>PROXY</KBD>, <KBD>SSLTUNNEL</KBD>, <KBD>SOCKS</KBD>,
or an origin server specified in <KBD>SERVER</KBD> or
in the right-hand of <KBD>MOUNT</KBD>.
<P>
If a list is prefixed with "/R", the servers in the list are tried
in random order (the first server to be tried is selected randomly and
other servers are tried in the round-robin order).
It could be useful for load balancing among equivalent (proxy) servers.
<P>
The retrial by this parameter is commonly applied to servers of any protocols
in the phase of establishment of a TCP connection to a server.
The retrial covers the authentication phase for several protocols.
In HTTP origin/gateway servers, the retrial may be caused depending on
the response from the server, including the response code 503
(Service Unavailable) and 404 (Not Found) for example.
<P>
Example:
<KBD>
<UL>
CLUSTER=http:www1,www2,www3..8080 MOUNT="/* http://www1/*"<BR>
CLUSTER=ftp:ftp1,ftp2,ftp3  MOUNT="/* ftp://ftp1/*"<BR>
CLUSTER=http-proxy:/R,px1..8080,px2..9090,px3..8080 PROXY=px1:8080<BR>
CLUSTER=socks:/R,sock1,sock2,sock3 SOCKS=socks1<BR>
</UL>
</KBD>
</UL>
</A>

<A NAME=CMAP>
<A NAME=connMap TITLE="Connection map">
<PRE>
CMAP parameter*     ==  CMAP=<I>resultStr</I>:<I>mapName</I>:<I>connMap</I>
           <I>connMap</I>  ==  <I>ProtoList</I>:<I>dstHostList</I>:<I>srcHostList</I>
                    --  default: none
</PRE>
<UL>
A generic parameter to make some parameters be conditional on the current connection.
When the protocol, the destination and the source
of the current connection match the <I>connMap</I>,
this map is enabled providing <I>resultStr</I> string
to be used for <I>mapName</I>.
<BR>
Not only host name/address but also port number of destination servers
can be used for matching in <A HREF="#portList"><I>dstHostList</I></A>.
A typical usage of this parameter is for applying
<A HREF="#cond-filter"><I>filter</I></A> conditionally.
</UL>
</A>
</A>

<A NAME=TLSCONF>
<PRE>
TLSCONF parameter*  ==  TLSCONF=<I>tlsConf</I>[,<I>tlsConf</I>]*
           <I>tlsConf</I>  ==  <I>what</I>:<I>value</I>
                    --  default: TLSCONF=scache:do,xcache:do
</PRE>
<UL>
<DL>
<DT>-v[d|s]
<DD>specify the detailness of logging of TLS setup and relay.
"-vd" make logging detailed whereas "-vs" suppresses any logging.
<P>
<DT>scache[:[do]|no|acc|con]
<DD>enable or disable the session caches.
By default, both session caches for accept and connect are enabled.
"no" disables both of these caches. "acc" enables only the cache
for clients. "con" enables only the cache for servers.
<P>
<DT>xcache[:[do]|no|acc|con]
<DD>
enable or disable the context cache for certificates of this DeleGate.

<DT>shutdown | shutdown:flush | shutdown:wait | shutdown:none
<DD>enable sending the shutdown alert (close notify) to the peer
before disconnection.
It is enabled by default for FTP (TLSCONF="shutdown" is preset for
SERVER="ftp" or SERVER="ftps").

<DT>libs:<I>libname</I>[+<I>libname</I>]
<DD>
specify the dynamic libraries for SSL in the order to be loaded instead
of the default ones, as TLSCONF="libs:crypto+ssl" for example.
A <I>libname</I> can be with a version number like "libssl.so.0.9.8" or
in a full-path name like "/usr/local/lib/libcrypto.0.9.8.dylib".
</DL>
</UL>
</A>

<A NAME=STLS TITLE="TLS negotiation control">
<PRE>
STLS parameter*     ==  STLS=<I>stlsSpecs</I>[,<I>sslwayCom</I>][:<I>connMap</I>]
         <I>stlsSpecs</I>  ==  [-]<I>stlsSpec</I>[/im][/ssl][,<I>stlsSpecs</I>]
          <I>stlsSpec</I>  ==  fsv | fcl | mitm | im<I>imSec</I>
         <I>sslwayCom</I>  ==  {sslway [-Vrfy] [-CApath dir] ...}
           <I>connMap</I>  ==  <I>ProtoList</I>:<I>dstHostList</I>:<I>srcHostList</I>
                    --  default: none
                    --  restriction: applicable to HTTP, FTP, SMTP, POP, IMAP, SOCKS
                    --  required: <A HREF=#serv_SSL>SSLway</A>
</PRE>
<UL>
This parameter controls the initiation of SSL (TLS) based on a negotiation
between client and server in each application protocol.
The common scheme of the negotiation is known as "STARTTLS".
"fsv" specifies using SSL with server and "fcl" specifies using SSL with client.
When SSL is not supported on a connection, the STARTTLS negotiation will fail
and the connection will be closed by default.
To continue a session even when SSL is not available,
prefix "-" to "fsv" or "fcl".
<P>
If "fcl" is specified, a client may start SSL without STARTTLS negotiation.
Such implicit SSL negotiation from the client-side is detected by peeping
a SSL hand-shake packet on the connection from the client-side at the
beginning of a session for a certain period specified with im<I>imSec</I>.
The default value is "im0.25" (250m seconds).
"-im" disables this implicit SSL negotiation.
If a <I>stlsSpec</I> is followed with "/im" as STLS="fsv/im" for example,
SSL with the peer (with the server in this case) is applied without
the STARTTLS negotiation.
<P>
<A NAME=mitm TITLE="Man-In-The-Middle-Mode">
If "mitm" is specified, it behaves like "-fcl,-fsv" that is  
if SSL is enabled in the client side then SSL on the server side is enabled.
It can be used with a HTTP proxy DeleGate as a "secure proxy" or "SSL-tunnel"
to peep the bidirectional communication in CONNECT method,
relaying it as a usual HTTP applying filters and cache.
("mitm" means "Man-In-The-Middle" mode)
If it is set optional as "STLS=-mitm" then the MITM mode is activated
only when the client specified the server name prefixing with "-mitm."
as "https://-mitm.host.domain/" for "https://host.domain/".
</A>
<P>
If non default SSLway command path or options are necessary to be used,
the SSLway command can be specified after <I>stlsSpecs</I> as
STLS="fcl,sslway -Vrfy -cert mycert.pem" for example.
<P>
Example:
<UL>
<KBD>
STLS="fcl" </KBD>-- use SSL with client (exit the session if not available)<BR><KBD>
STLS="-fcl" </KBD>-- use SSL with client if available<BR><KBD>
STLS="fsv,-fcl" </KBD>-- use SSL with server, and with client if available<BR><KBD>
STLS="fsv/ssl" SERVER="ftp" </KBD>-- use AUTH SSL instead of AUTH TLS<BR><KBD>
STLS="fsv,im0.5" SERVER="ftp" </KBD>-- automatic detection of implicit/explicit SSL server<BR><KBD>
</KBD>
</UL>
</UL>
</A>

<A NAME=CERTDIR TITLE="certificates repository">
<PRE>
CERTDIR parameter   ==  CERTDIR=<I>dir</I>
                    --  default: ${ETCDIR}/certs
                    --  version: DeleGate/9.8.0 + OpenSSL0.9.8g or laters
</PRE>
<UL>
CERTDIR specifies the directory as the repository of certificates to be used
by <A HREF=#serv_SSL>SSLway</A>.
Certificate files in the directory are named as follows.
All of these files are optional.
<P>
<DL>
<DT><KBD>me.pem</KBD> -- my certificate
<DD>The certificate of this DeleGate to be sent to clients (and to servers
if requested).
It may contain the private-key too.
It can be a chained certificate followed with the certificates of
intermediate CAs.
<DT><KBD>me-key.pem</KBD> -- my private-key
<DD>This file is necessary if the private-key for <KBD>me.pem</KBD> is not
contained in itself.
<DT><KBD>me-key.pas</KBD> -- the pass-phrase for my private-key
<DD>This file is necessary if the private-key in <KBD>me-key.pem</KBD> is
encrypted.
<!--
<DT><KBD>common-key.pem</KBD>
-->
<DT><KBD>common.pas</KBD> -- the pass-phrase common to private-keys
<DD>This file can be used as the default pass-phrase common to
all encrypted private-keys.

<DT><KBD>dhparam.pem</KBD> -- DH PARAMETERS
<DD>This file is necessary to enable ciphers using Diffie-Hellman algorithm.

<DT><KBD>sn.<I>domain</I>.pem</KBD> -- the certificate for SNI
<DD>The certificate for the <I>domain</I> indicated by SNI
(Server Name Indication).
Like me.pem, it may be in the combination of
sn.<I>domain</I>-key.pem and sn.<I>domain</I>-key.pas (or common.pas).
<!--
If the <I>domain</I> string starts with "." then it is used for sub-domains
of it like "xxx.<I>domain</I>".
-->
<DT><KBD>sa.<I>address</I>.pem</KBD> -- my certificate to clients
<DD>The certificate to be sent to clients when accessed via the network
interface with <I>address</I> (ex. "sa.127.0.0.1.pem").

<DT><KBD>to-sv.pem</KBD> -- my certificate to servers
<DD>The certificate like me.pem which is sent to servers only.
<DT><KBD>to-cl.pem</KBD> -- my certificate to clients
<DD>The certificate like me.pem which is sent to clients only.
<!--
<DT><KBD>to-sv-<I>domain</I>.pem</KBD>
 -- the certificate sent to the server domain
<DT><KBD>to-cl-<I>domain</I>.pem</KBD>
 -- the certificate sent to the client domain
<DT><KBD>to-if-<I>domain</I>.pem</KBD>
 -- the certificate sent via the interface
<DT><KBD><I>cert</I>.opts</KBD> -- options for the certificate
-->
<DT><KBD>ca-sv.pem</KBD> -- servers' CAs' certificates
<DD>The certificates of CAs to be used to verify acceptable certificates
shown by servers.  It may contain CRL too.
<DT><KBD>ca-sv/</KBD> -- directory of certificates of servers' CAs
<DD>each <I>certificate</I> is named with
 'openssl x509 -hash -noout < <I>certificate</I>.pem'
<DT><KBD>ca-cl.pem</KBD> -- clients' CAs' certificates
<DD>The certificates of CAs to be used to verify acceptable certificates
shown by clients.  It may contain CRL too.
<DT><KBD>ca-cl/</KBD> -- directory of certificates of clients' CAs 
<DD>each <I>certificate</I> is named with
 'openssl x509 -hash -noout < <I>certificate</I>.pem'
</DL>
<P>
<!--
The existence of ca-sv.pem or ca-cl.pem is equivalent to and
can be overridden by "sslway -Vrfy -cert ca-sv.pem" option.
-->
</UL>
</A>

<A NAME=DGCONF>
<PRE>
DGCONF parameter    ==  DGCONF=<I>dir</I>/<I>file</I>
                    --  default: DGCONF='${EXECDIR}/${EXECNAME}.conf'
</PRE>
<UL>
DGCONF specifies the file of configuration parameters to be loaded,
if exists, on the invocation.
The default value is relative to the name of the executable file of
DeleGate.  For example, if the path of the executable is
"X:/path/of/dg9_4_1.exe" then DGCONF="X:/path/of/dg9_4_1.conf".
</UL>
</A>

<A NAME=DYCONF>
<PRE>
DYCONF parameter*   ==  DYCONF=[<I>conditions</I>]<I>parameters</I>
        <I>parameters</I>  ==  file:<I>path</I> | cgi:<I>path</I> | arg:{<I>listOfParameters</I>}
                    --  default: none
</PRE>
<UL>
DYCONF specifies configuration parameters to be loaded dynamically
on the beginning of relaying application protocol
after the acception of a TCP connection from a client
before starting a session over it.
The loading of parameters can be conditional based on the specified
<I>conditions</I>,
and the parameter value can be generated and/or evaluated
on each loading.
<P>
A condition for loading can be based on the identity (address or name)
of the host of a client which is requesting over the new connection.
Or it can be based on the content (sub-string or pattern) of
the initial request data which is sent from a client over a connection.
The request data is polled for a specified period (15sec. by default)
and peeked by a specified size (4K bytes at max. by default).
<P>
Conditions:<UL>
<DL>
<DT><KBD>qstr/<I>string</I>    </KBD> ... matching by request sub-string
<DT><KBD>qreq/<I>pattern</I>   </KBD> ... matching by request pattern
<DT><KBD>{from/<I>hostList}</I></KBD> ... matching by client hosts
<DT><KBD>excl[/<I>number</I>]  </KBD> ... exclusive with other DYCONFs
<DT><KBD>poll/<I>seconds</I>   </KBD> ... timeout of polling request [4k]
<DT><KBD>peek/<I>bytes</I>     </KBD> ... max. bytes of peeking request [15.0s]
<DT><KBD>skip                  </KBD> ... purge peeked data before starting relay
<DT><KBD>debug                 </KBD> ... enable logging for debugging of DYCONF
</DL>
</UL>
<P>
Example:<UL>
<KBD>
DYCONF="file:path.txt"  # load parameters from path.txt<BR>
DYCONF="cgi:path.cgi"   # load parameters generated by path.cgi<BR>
DYCONF="qstr/string,arg:{SERVER=tcprelay://sv1:1234;TIMEOUT=io:3}"<BR>
DYCONF="{qrex/[a-z][0-9]*},arg:{SERVER=tcprelay://sv1:1234}"<BR>
</KBD>
</UL>
</UL>
</A>

<A NAME=DYLIB>
<PRE>
DYLIB parameter     ==  DYLIB=<I>libfilePattern</I>[,<I>libfilePattern</I>]*
                    --  default: DYLIB='dglib*.so,lib*.so,dglib*.dylib,lib*.dylib'
</PRE>
<UL>
DYLIB specifies a list of file name patterns for dynamic linking
library files to be retrieved.  The character "*" in each pattern is
replaced with the library name to be retrieved, for example with
a pattern "lib*.so", "libssl.so" is retrieved for "ssl". 
A special pattern "+" means to include the default list.
If a pattern is not in full-path format, the library file will be
retrieved in some directories which depends on the system configuration
or an environment variable like LD_LIBRARY_PATH or so.
A pattern can be in full-path like "/usr/local/ssl/lib/lib*.so", or
without "*" character like "/usr/local/ssl/lib/libssl.so".
<P>
Example:
<UL>
<KBD>
DYLIB="" ... disable dynamic linking<BR>
DYLIB="lib*.so,lib*.so.1"<BR>
DYLIB="libz.so,libssl.so"<BR>
DYLIB="+,lib*.so.0.9.7"<BR>
DYLIB="/usr/lib/libz.so.1,/lib/libssl.so"<BR>
</KBD>
</UL>
</UL>
</A>

<A NAME=LDPATH>
<PRE>
LDPATH parameter    ==  LDPATH=<I>dirPath</I>[;<I>dirPath</I>]*
                    --  default: LDPATH='${LIBDIR};${EXECDIR};${HOME}/lib;/usr/lib;/lib'
</PRE>
<UL>
Specify where dynamic libraries (<A HREF=#DYLIB>DYLIB</A>) are searched.
</UL>
</A>

<A NAME=LIBPATH>
<A NAME=STARTDIR>
<A NAME=LIBDIR>
<A NAME=EXECDIR>
<PRE>
LIBPATH parameter   ==  LIBPATH=<I>dirPath</I>[:<I>dirPath</I>]*
                    --  default: LIBPATH='.:${STARTDIR}:${LIBDIR}:${EXECDIR}:${ETCDIR}'
</PRE>
<UL>
Library files, including parameter files,
CFI scripts and filter programs,
are searched in multiple directories in order specified in LIBPATH
if it is specified as relative path.
By default, LIBPATH is a ordered list of the following directories:<BR>
<UL>
<KBD>WORKDIR</KBD> (.) -- the working directory<BR>
<KBD>STARTDIR</KBD> -- the directory where the DeleGate is invoked<BR>
<KBD>LIBDIR</KBD> -- <KBD>${DGROOT}/lib</KBD> by default<BR>
<KBD>EXECDIR</KBD> -- the directory where the executable file of DeleGate is placed<BR>
<KBD>ETCDIR</KBD> -- <KBD>${DGROOT}/etc</KBD> by default<BR>
</UL>
</UL>
</A>
</A>
</A>
</A>

<A NAME=DATAPATH>
<PRE>
DATAPATH parameter  ==  DATAPATH=<I>dirPath</I>[:<I>dirPath</I>]*
                    --  default: DATAPATH='.:${DGROOT}:${STARTDIR}
</PRE>
<UL>
The list of directories each contains data files to be provided to
client.  This parameter is used by a DeleGate which generates response
data from local file specified in relative path like
MOUNT="/<I>path</I>/* file:<I>dir</I>/*".
</UL>
</A>

<A NAME=DGPATH>
<PRE>
DGPATH parameter    ==  DGPATH=<I>dirPath</I>[:<I>dirPath</I>]*
                    --  default: DGPATH='+:.:${HOME}/delegate:${EXECDIR}:${ETCDIR}'
</PRE>
<UL>
The search path of parameter files.
A special directory name "+" stands for the place
where the "caller" resource
(a parameter file referring the parameter file) is.
</UL>
</A>

<A NAME=DGSIGN>
<PRE>
DGSIGN parameter    ==  DGSIGN=<I>signatureSpec</I>
                    --  default: DGSIGN="V.R.P/Y.M.D"
</PRE>
<UL>
Specify the signature of the DeleGate to be shown to client or server.
The full form signature "Version.Revision.Patch (Month Day, Year)" is
represented as "V.R.P/Y.M.D".  To hide the a specific part, replace the
corresponding character with "x".  For example, DGSIGN="V.x.x/Y.x.x"
will make signature like "DeleGate/9.x.x (x x, 2005)".
</UL>
</A>

<A NAME=DGOPTS>
<PRE>
DGOPTS parameter    ==  DGOPTS=<I>opt</I>[,<I>opt</I>]*
                    --  default: none
</PRE>
<UL>
A list of command line options.
This may be useful when those options like -P or -v,
not in <I>name</I>=<I>value</I> format,
are to be given in an environment variable.
</UL>
</A>

<A NAME=SOCKOPT>
<PRE>
SOCKOPT parameter*  ==  SOCKOPT=[no]<I>name</I>[:<I>value</I>]
                    --  default: reuse
</PRE>
<UL>
Set socket options.
<P>
<DL>
<DT>[reuse] | noreuse
<DD>enables instant reuse of a port number. (SO_REUSEADDR)
<DT>share | [noshare]
<DD>enables simultaneous use of a port. (SO_REUSEPORT)
<DT>[shut] | noshut
<DD>do shutdown(socket,SD_SEND) before closing a socket
<DT>shutdown:g[:<I>connMap</I>]
<DD>do graceful shutdown (for HTTP response) on Win32
<DT>buffsize:<I>size</I>[kiosc][:<I>connMap</I>]
<DD>set the size of socket buffers.
The <I>size</I> value can be followed with following specifiers:<UL>
<KBD>k</KBD> -- size in kilo bytes<BR>
<KBD>i</KBD> -- input buffer (SO_RCVBUF)<BR>
<KBD>o</KBD> -- output buffer (SO_SNDBUF)<BR>
<KBD>s</KBD> -- socket to server<BR>
<KBD>c</KBD> -- socket from client<BR>
</UL>
For example, SOCKOPT="buffsize:2kis" set the size of the socket buffer
to receive data from a server to 2048 bytes.
Multiple buffer size specifications can be concatenated with "+".
For example,
SOCKOPT="buffsize:2k" is equivalent to
SOCKOPT="buffsize:2kis+2kos+2kic+2koc:*:*:*".
<DD>
</DL>
</UL>
</A>

<A NAME=PORT>
<PRE>
PORT parameter      ==  PORT=<I>port</I>[,<I>port</I>]*
              <I>port</I>  ==  [<I>host</I>:]<I>portNum</I>[/udp]
           <I>portNum</I>  ==  <I>number</I>[-<I>number</I>]
                    --  default: none
</PRE>
<UL>
Make entrance ports as -P option does.
</UL>
</A>

<A NAME=FORWARD>
<PRE>
FORWARD parameter*  ==  FORWARD=<I>gatewayURL</I>[-_-<I>connMap</I>]
        <I>gatewayURL</I>  ==  <I>gwproto</I>://[<I>user</I>:<I>pass</I>@]<I>gwhost</I>[:<I>gwport</I>]
           <I>connMap</I>  ==  <A HREF="#ProtoList"><I>protoList</I></A>:<A HREF="#HostList"><I>dstHostList</I></A>:<A HREF="#HostList"><I>srcHostList</I></A>
                    --  default: none
</PRE>
<UL>
Forwards a request
toward a proxy server specified in <I>gatewayURL</I>
if the request matches the condition specified in <I>connMap</I>,
that is, the request is in a protocol listed in <I>protoList</I> and 
for servers listed in <I>dstHostList</I> and
from clients in <I>srcHostList</I>.
If <I>connMap</I> is omitted, any request are forwarded to the
<I>gatewayURL</I> unconditionally.
If an authentication information is given as "<I>user</I>:<I>pass</I>@"
prefixed to <I>gwhost</I>, it is used on the authentication phase
after the connection with the <I>gwhost</I>.
<BR>
FORWARD is a generalized notation of ROUTE and
the following two notations are equivalent.
<P>
<UL>
<A HREF="#ROUTE">ROUTE</A>=<I>gwproto</I>://<I>gwhost</I>:<I>gwport</I>/-_-<I>dstHostList</I>:<I>srcHostList</I><BR>
FORWARD=<I>gwproto</I>://<I>gwhost</I>:<I>gwport</I>/-_-*:<I>dstHostList</I>:<I>srcProtoList</I>
</UL>
<P>
For special <I>gwproto</I>, FORWARD works as a generalized notation of
MASTER, PROXY, SOCKS and SSLTUNNEL as follows.
<P>
<DL>
<DT>delegate
-- forward to a DeleGate
<DD>
<A HREF="#MASTER">MASTER</A>=<I>gwhost</I>:<I>gwport</I>:<I>dstHostList</I><BR>
FORWARD=delegate://<I>gwhost</I>:<I>gwport</I>/-_-*:<I>dstHostList</I>:*

<DT>http, ftp, telnet
-- forward to an application level proxy (HTTP, FTP, or Telnet)
<DD>
<A HREF="#PROXY">PROXY</A>=<I>gwhost</I>:<I>gwport</I>:<I>dstHostList</I><BR>
FORWARD=<I>gwproto</I>://<I>gwhost</I>:<I>gwport</I>/-_-*:<I>dstHostList</I>:*

<DT>socks
-- forward to a SOCKS server
<DD>
<A HREF="#SOCKS">SOCKS</A>=<I>gwhost</I>:<I>gwport</I>[/<I>socksOpt</I>]:<I>dstHostList</I>:<I>srcHostList</I><BR>
FORWARD=socks://<I>gwhost</I>:<I>gwport</I>[/<I>socksOpt</I>]-_-*:<I>dstHostList</I>:<I>srcHostList</I>

<DT>ssltunnel
-- forward to a SSL-tunnel (HTTP proxy with the CONNECT method)
<DD>
<A HREF="#SSLTUNNEL">SSLTUNNEL</A>=<I>gwhost</I>:<I>gwport</I><BR>
FORWARD="ssltunnel://<I>gwhost</I>:<I>gwport</I>/-_-*:*:*"

<DT>direct
-- directly connect to the server
<DD>
<A HREF="#CONNECT">CONNECT</A>="direct:<I>protoList</I>:<I>dstHostList</I>:<I>srcHostList</I>"<BR>
FORWARD="direct-_-<I>protoList</I>:<I>dstHostList</I>:<I>srcHostList</I>"

<DT>noroute
-- don't try connection to the server
<DD>
<A HREF="#CONNECT">CONNECT</A>="cache:<I>protoList</I>:<I>dstHostList</I>:<I>srcHostList</I>"<BR>
FORWARD="noroute-_-<I>protoList</I>:<I>dstHostList</I>:<I>srcHostList</I>"
</DL>
<P>
If multiple FORWARD parameters are specified, they are tried in the order
of the definition. 
If multiple routes to the destination server are available,
specified with a mixture of FORWARD and other parameters
(MASTER, PROXY, SOCKS or SSLTUNNEL),
the route defined by FORWARD is tried in precedence defined by "proxy" or
"master" in <A HREF="#CONNECT">CONNECT</A>.

<P>
Example: a gateway for HTTP clients to a HTTPS server reachable via SSLtunnel with authentication
<UL>
<KBD>
MOUNT="/* https://sslhost/*" <BR>
STLS=fsv:https:sslhost<BR>
FORWARD=ssltunnel://user:pass@proxyhost:8080-_-https:sslhost
</KBD>
</UL>
</UL>
</A>

<A NAME=ROUTE>
<PRE>
ROUTE parameter*    ==  ROUTE=<I>proto</I>://<I>host</I>:<I>port</I>/-_-<I>dstHostList</I>:<I>srcHostList</I>
                    --  default: none
</PRE>
<UL>
Forwards requests from hosts in <I>srcHostList</I>
to the resources listed in <I>dstHostList</I>
toward the server at <I>host</I>:<I>port</I>
in <I>proto</I> protocol.
ROUTE is a generalized notation for MASTER and PROXY.
MASTER="<I>host</I>:<I>port</I>:<I>dstHostList</I>" is the abbreviation of
ROUTE="delegate://<I>host</I>:<I>port</I>/-_-<I>dstHostList</I>:*".
PROXY="<I>host</I>:<I>port</I>:<I>dstHostList</I>"
      with SERVER=<I>proto</I> is equals to
ROUTE="<I>proto</I>://<I>host</I>:<I>port</I>/-_-<I>dstHostList</I>:*".
<P>
A host specification in the <I>dstHostList</I> may be
prefixed with "<I>proto</I>://"
to restrict the protocol to be forwarded.  For example,
ROUTE="http://<I>host</I>:<I>port</I>/-_-{ftp://*}:*"
means that only access to FTP servers are forwarded
to the HTTP-proxy at "http://<I>host</I>:<I>port</I>/".
<P>
A host specification in the <I>dstHostList</I> can be restricted further
with port number.
For example, ROUTE="http://<I>host</I>:<I>port</I>/-_-{*:21}:*" means that
only accesses to the port number 21 (FTP service) is forwarded to the
proxy.
</UL>
</A>

<A NAME=MASTER>
<PRE>
MASTER parameter*   ==  MASTER=<I>host</I>:<I>port</I>[/<I>masterControl</I>][:<I>dstHostList</I>]
                    --  default: none
</PRE>
<UL>
This parameter specifies an upstream generalist DeleGate (MASTER-DeleGate)
to which this DeleGate will forward requests.
Forwarding to a MASTER-DeleGate can be filtered
by postfixing ":<I>dstHostList</I>";
only request toward destination servers listed in <I>dstHostList</I> are
forwarded to the MASTER-DeleGate.
When multiple MASTERs are given, they are tried in order until connection
to a MASTER succeed.
<P>
Optional "/<I>masterControl</I>" can be:
    <UL>
    cache    -- use the MASTER only if cache hits in the MASTER<BR>
    teleport -- make a persistent <I>Teleport</I> connection to the MASTER
    </UL>
</UL>
</A>

<A NAME="MASTERP">
<PRE>
MASTERP parameter   ==  MASTERP=[<I>host</I>:<I>port</I>]
                    --  default: none
</PRE>
<UL>
Invoke a MASTER-DeleGate private to this DeleGate.
HTTP-DeleGate working as a gateway to another protocol needs
MASTER-DeleGate to do <I>connection cache</I> for FTP and NNTP.
MASTERP may be specified with MASTER to force data caching at
the local host when the MASTER is running at a remote host.
</UL>
</A>

<A NAME=RPORT>
<PRE>
RPORT parameter     ==  RPORT={tcp|udp}[:<I>host</I>]
                    --  default: none
</PRE>
<UL>
This parameter should be used together with MASTER parameter.
If specified, a connection (for response data transfer) from the
MASTER-DeleGate to this DeleGate is established separately from the
connection (for request data transfer) from the DeleGate to its
MASTER-DeleGate.  A specified type of response connection will be
made from the MASTER toward the delegate at the specified host.
</UL>
</A>

<A NAME="PROXY">
<PRE>
PROXY parameter*    ==  PROXY=<I>host</I>:<I>port</I>[:<I>dstHostList</I>]
                    --  default: none
                    --  restriction: applicable to HTTP, FTP, Telnet
</PRE>
<UL>
Specify an upstream proxy (specialist DeleGate or standard proxies)
to which the DeleGate should forward requests.
If <I>dstHostList</I> is specified, forwarding to the upstream proxy
is done only when the destination host is in the list.
Only HTTP, FTP, and Telnet specialist DeleGate can specify this parameter.
<P>
Example:
<UL>
<KBD>
SERVER=http PROXY=<I>proxyhost</I>:8080:!*.localdomain<BR>
SERVER=ftp PROXY=<I>proxyhost</I>:<I>proxyport</I>  
</KBD>
</UL>
</UL>
</A>

<A NAME=SOCKS>
<A NAME=Socks>
<PRE>
SOCKS parameter*    ==  SOCKS=<I>host</I>[:[<I>port</I>][/<I>socksOpt</I>][:<I>dstHostList</I>[:<I>srcHostList</I>]]]
          <I>socksOpt</I>  ==  [ -4 | -r ]*
                    --  default: none
</PRE>
<UL>
Specify to use Socks server on <I>host</I>.  The server is expected
to recognize Socks version 5 protocol.  If the server supports only
version 4, specify "-4" option like "SOCKS=<I>host</I>:<I>port</I>/-4".
<BR>
The "-r" option controls which of DeleGate or Socks server does the name
resolution (from the host name of a target host to its IP address).
With a SocksV4 server, name resolution is done by DeleGate by default.
"-r" option make the resolution be delegated to the server
(This is applicable if the server supports extended Socks4A protocol).
With a SocksV5 server, name resolution is delegated to the server
by default, and "-r" option make the resolution be done locally by DeleGate.
<BR>
By default, the connection establishment via Socks will be tried
after all of other trials failed, but you can control the order by
the <A HREF="#CONNECT">CONNECT</A> parameter. 
<BR>
If the <I>dstHostList</I> part is omitted, the default value for it is
"!<A HREF="#localnet">.localnet</A>".  This default value can be changed
by redefining the named HostList "<A HREF="#HOSTLIST_predef">.socksdst</A>"
which is predefined as <KBD>HOSTLIST=".socksdst:!.localnet"</KBD>
<P>
Example:
<UL>
<KBD>
CONNECT=s,d
SOCKS="<I>sockshost</I>:1080:!.localnet,!*.my.domain"<BR>
</KBD>
</UL>
</UL>
</A>
</A>

<A NAME="SSLTUNNEL">
<PRE>
SSLTUNNEL parameter ==  SSLTUNNEL=<I>host</I>:<I>port</I>
                    --  default: none
</PRE>
<UL>
Use a HTTP proxy with  the standard <I>SSL tunneling</I> feature
(on HTTP with CONNECT method)
running at <I>host</I>:<I>port</I> as a circuit level proxy
for target servers of arbitrary protocols.
</UL>
</A>

<A NAME="VSAP">
<PRE>
VSAP parameter      ==  VSAP=<I>host</I>:<I>port</I>
                    --  default: none
</PRE>
<UL>
Specify a VSAP server to be used for accepting from clients or for
connecting to clients.  VSAP is a remote socket mapping server
which enables servers to accept a TCP connection via a remote host
as well as to connect via a remote host.
<P>
Example:
<UL>
    // VSAP server<BR>
<KBD>
<I>firewall</I>% delegated -P8000 SERVER=vsap PORT=8080-8090<BR>
</KBD>
    // accept via VSAP
       to provide internal servers for external clients<BR>
<KBD>
<I>internal</I>% delegated -P8080@<I>firewall</I>:8000 ...<BR>
</KBD>
    // connect via VSAP,
       working as a proxy server for internal clients<BR>
<KBD>
<I>internal</I>% delegated -P8080 CONNECT="{vsap/<I>firewall</I>:8000}" ...<BR>
</KBD>
    // accept and connect via VSAP server<BR>
<KBD>
<I>internal</I>% delegated -P8080 VSAP=<I>firewall</I>:8000 ...<BR>
</KBD>
</UL>
</UL>
</A>

<A NAME=YYMUX>
<PRE>
YYMUX parameter*    ==  YYMUX=<I>host</I>[:<I>port</I>][:<I>connMap</I>]
           <I>connMap</I>  ==  <I>ProtoList</I>[:<I>dstHostList</I>[:<I>srcHostList</I>]]
                    --  default: none
</PRE>
<UL>
This parameter specifies a <A HREF=#serv_YYMUX>YYMUX server</A>
to be used as an upstream proxy server of this DeleGate.
The connection established to the YYMUX server, to be used to
tunnel and multiplex TCP/IP connections over it, is retained
as if it is persistent.
If the tunnel is broken before the disconnection of the tunneled
TCP/IP connections, for example when the host of this DeleGate
changed its IP-address, the YYMUX tunnel is reconnected and
restored based on the resumption protocol of the YYMUX protocol.
</UL>
</A>

<A NAME=YYCONF>
<PRE>
YYCONF parameter*   ==  YYCONF=<I>name</I>[:<I>value</I>]
                    --  default: none
</PRE>
<UL>
Example:
<UL><KBD>
YYMUX="HOME:/user/xxxx"<BR>
YYMUX="SHELL:/bin/csh -l"<BR>
</KBD></UL>
</UL>
</A>

<A NAME="CONNECT">
<PRE>
CONNECT parameter*  ==  CONNECT=<I>connSeq</I>[:<I>connMap</I>]
           <I>connSeq</I>  ==  <I>connType</I>[,<I>connType</I>]*
          <I>connType</I>  ==  cache|icp|proxy|master|https|vsap|direct|socks|udp
           <I>connMap</I>  ==  <I>ProtoList</I>[:<I>dstHostList</I>[:<I>srcHostList</I>]]
                    --  default: CONNECT="c,i,m,h,y,v,s,d:*:*:*"
</PRE>
<UL>
This parameter controls the order of trials for connection to the
target server using several connection method as followings:
<P>
<I>connType</I>:
<UL>
<TABLE BORDER=0 CELLSPACING=0>
<TR><TD>cache <TD> -- CACHE search (without connection)<BR>
<TR><TD>icp   <TD> -- via a PROXY hinted by ICP server<BR>
<TR><TD>proxy <TD> -- via a PROXY server<BR>
<TR><TD>master<TD> -- via a PROXY or a MASTER-DeleGate server<BR>
<TR><TD>https <TD> -- via a SSLTUNNEL (SSL tunnel on HTTP)<BR>
<TR><TD>yymux <TD> -- via a <A HREF=#YYMUX>YYMUX</A> server<BR>
<TR><TD>vsap  <TD> -- via a VSAP server<BR>
<TR><TD>direct<TD> -- direct connection to the target server<BR>
<TR><TD>socks <TD> -- via SOCKS servers<BR>
<TR><TD>udp   <TD> -- by UDP<BR>
<TR><TD>None  <TD> -- don't connect<BR>
</TABLE>
</UL>
<P>
Each connection type can be abbreviated by the first character as
{c,i,m,d,v,s,u} respectively.<BR>
If ProtoList and dstHostList are given, this control is applied only
to the protocols and hosts included in the lists.  For example,
to use cached data in a host which is not connected to external networks,
specify as CONNECT="cache:*:!./@".
<P>
Note:
In current implementation, "cache" will be tried first anyway if it is
included in the <I>connSeq</I>.
</P>
A combination of -P<I>port</I> with CONNECT=udp relays from TCP client
to UDP server,
and -P<I>port</I>/udp with non-udp CONNECT relays from UDP client
to TCP server.
</UL>
</A>

<A NAME="SRCIF">
<PRE>
SRCIF parameter*    ==  SRCIF=<I>host</I>[:[<I>port</I>][:<I>connMap</I>]]
           <I>connMap</I>  ==  <I>ProtoList</I>:<I>dstHostList</I>:<I>srcHostList</I>
                    --  default: SRCIF="*:*:*:*:*"
</PRE>
<UL>
This parameter is useful for DeleGate running on a multi-homed host or
on a host behind a firewall with packet filtering.
<P>
This parameter specifies the source address (of a network interface) of each
connection to a server.
This can be useful when the host of DeleGate has multiple network interfaces.
Also it can be used to specify the port to be used for accepting
a client connection by a SOCKS-DeleGate or a FTP-DeleGate.
<P>
In most cases, a special pattern "*" as <I>host</I> or <I>port</I> specifies
the wild-card IP address or port number.
In some cases, the special pattern "*" is used for the desired address and number
which is specified by a protocol,
like a port for <A HREF=#serv_FTP>FTP</A> data connection (by PORT or PASV)
or a port for <A HREF=#serv_Socks>SOCKS</A> (BIND and UDP-ASSOCIATE).
To explicitly specify the wild-card as an IP address and port number,
use "0.0.0.0" as <I>host</I> and "0" as <I>port</I> respectively.
<P>
Example:
<UL>
<KBD>SRCIF="*:0:ftp-data"</KBD>
// use a random port number for FTP data connection<BR>
<KBD>SRCIF="*:8020-8120:ftp-data"</KBD>
// use a port number in the specified range<BR>
<KBD>SRCIF="150.29.202.120:*:tcpbind"</KBD>
// use the specified address to accept via SOCKS<BR>
<KBD>SRCIF="150.29.202.120:*:udpbind"</KBD>
// use the specified address to relay UDP on SOCKS<BR>
</UL>
<P>
The port for "ftp-data" connection which is assigned on demand and notified
to the peer,
that is from client to server by PORT or from server to client by PASV,
can be controlled separately by "ftp-data-port" or "ftp-data-pasv" respectively.
The source port for data connection, which is established from server to
client for PORT or from client to server for PASV,
can be controlled by "ftp-data-src".
</UL>
</A>

<A NAME=TUNNEL>
<A NAME=tunnel>
<PRE>
TUNNEL parameter    ==  TUNNEL=<I>tunnelType</I>:<I>script</I>
        tunnelType  ==  tty7
                    --  default: none
</PRE>
<UL>
If specified, communication with an upstream DeleGate will be <I>tunneled</I>
via the standard input/output of the command.
The tunnel can be made of any kind of channel,
a raw serial line for example,
as long as it provides bi-directional transmission on it.
Possibly it may be the channel to the DeleGate
which will be invoked from inetd at remote host.
<P>
Currently, the <I>tunnelType</I> must be "tty7" which means
transmission between DeleGates is done in 7bits stream.
When the type is "tty7", how the TUNNEL is established is described
in the specified <I>SHIO-script</I> file.
See "src/sample.shio" in the distribution package.
The name of a script file must be specified either in absolute path,
or in relative file name which will be retrieved in
<A HREF="#LIBPATH">LIBPATH</A>.
The upstream DeleGate for TUNNEL must be invoked with
<KBD>SERVER="tunnel1"</KBD>.
<P>
Example: make a tunnel without login dialogue
<UL>
<KBD>
TUNNEL=tty7:tunnel.shio
</KBD>
<BR>
[content of tunnel.shio]<BR>
<KBD>
o rsh <I>host</I> delegated SERVER=tunnel1\n<BR>
i READY\r\n<BR>
=<BR>
</KBD>
</UL>
Example: make a tunnel with login dialogue
<UL>
<KBD>
TUNNEL=tty7:tunnel.shio
</KBD>
<BR>
[content of tunnel.shio]<BR>
<KBD>
o telnet <I>hostname</I>\n<BR>
i login: <BR>
o <I>username</I>\n<BR>
i Password:<BR>
o <I>password</I>\n<BR>
i % <BR>
o delegated SERVER=tunnel1 \n<BR>
i READY\r<BR>
i \n<BR>
=<BR>
</KBD>
</UL>
As shown in above examples, the first line in a <I>SHIO-script</I> file is
expected to be a shell command like "o <I>command</I>\n" to establish a
connection to a remote server.
Another way to establish a connection is putting "c <I>host</I>:<I>port</I>"
on the first line.  No shell nor shell command is invoked in this case.
</UL>
</A>
</A>

<A NAME=PERMIT>
<PRE>
PERMIT parameter*   ==  PERMIT=<A HREF="#connMap"><I>connMap</I></A>
           <I>connMap</I>  ==  <A HREF="#ProtoList"><I>ProtoList</I></A>:<A HREF=#HostList><I>dstHostList</I></A>:<A HREF=#HostList><I>srcHostList</I></A>
                    --  default: none
</PRE>
<UL>
A PERMIT parameter specifies what kind of accesses should be
permitted by this DeleGate.  An access will be permitted if the
access is from a client host included in <I>srcHostList</I>,
and to a server host included in <I>dstHostList</I>,
and with a protocol included in <I>ProtoList</I>.
<P>
If multiple PERMIT parameters are given,
an access will be permitted if at least one of
those PERMITs indicates permission.
If no PERMIT parameter is given, access permission is controlled
by REMITTABLE, REACHABLE and RELIABLE parameters which can be
defined explicitly or implicitly depending on SERVER parameter.
<P>
Example:
unlimited permission to hosts on local net while only http://www to others
<UL>
<KBD>
PERMIT="*:*:<A HREF="#localnet">.localnet</A>"<BR>
PERMIT="http:www:*"<BR>
</KBD>
</UL>

<P>
The special pattern "*" in <I>ProtoList</I> (<I>dstHostList</I>) means
all of permitted protocols (servers), which may be explicitly
defined with REMITTABLE (REACHABLE) parameters.   These parameters
limits the widest possible permission.  A protocol (server) is not permitted
if it is not permitted in REMITTABLE (REACHABLE) parameters defined
implicitly or explicitly.
Similarly, if more than one RELIABLE parameters are given explicitly,
they limit the widest acceptable clients in <I>srcHostList</I> of PERMIT.
<P>
The host specifications in the <I>dstHostList</I> can be further restricted
with port number like "<I>host</I>:<I>portNumList</I>".
For example, PERMIT="telnet:{*:23}:*" means permitting
telnet to any host but only on the standard port number (23).
<P>
A protocol name in the <I>ProtoList</I> can be modified with port number
and method like "<I>protocolName</I>/<I>portNumList</I>/<I>methodList</I>"
to restrict accessible ports and methods in the protocol.
For example, a series of PERMIT parameters,
PERMIT="ftp//readonly:<I>Servers</I>:<I>Clients</I>"
PERMIT="ftp:*:*"
means inhibiting uploading to <I>Servers</I> from <I>Clients</I>
while allowing uploading among other combinations of servers and clients.
<P>
When multiple DeleGate servers are chained using MASTER or PROXY
parameter, the original client identification information got at
the first DeleGate server (at the entrance of the chain) can be
forwarded to the upstream DeleGate server using <A HREF="#RIDENT">RIDENT</A>
parameter and will be examined using PERMIT parameter.
</UL>
</A>


<A NAME=REJECT>
<PRE>
REJECT parameter*   ==  REJECT=<A HREF="#connMap"><I>connMap</I></A>
           <I>connMap</I>  ==  <A HREF="#ProtoList"><I>ProtoList</I></A>:<A HREF=#HostList><I>dstHostList</I></A>:<A HREF=#HostList><I>srcHostList</I></A>
                    --  default: none
</PRE>
<UL>
REJECT parameter specifies what kind of access is to be rejected
in the same syntax with <A HREF=#PERMIT>PERMIT</A>.
It can be more convenient than PERMIT
when cases to be rejected are exceptional and
are easier to describe than cases to be permitted.
<P>
Example:
forbid mail-clients to remove message on mail-servers
<UL>
<KBD>
REJECT="pop//DELE:mail-server:mail-client"<BR>
REJECT="imap//EXPUNGE:mail-server:mail-client"<BR>
</KBD>
</UL>
</UL>
</A>


<A NAME=REMITTABLE>
<PRE>
REMITTABLE parameter == REMITTABLE=<A HREF="#ProtoList"><I>ProtoList</I></A>
                    --  default: REMITTABLE="*" for generalist
                    --  default: REMITTABLE="." for specialist
</PRE>
<UL>
Only protocols (to the server) listed in <I>ProtoList</I> will be permitted
by this DeleGate.<BR>
For generalist (a DeleGate with SERVER="delegate" parameter) any
protocols are permitted by default.  For specialist, only the protocol
specified in the SERVER parameter (which can be represented by ".")
is permitted by default.
<P>
If a protocol name is followed by "/<I>portNumList</I>",
only ports listed in
the PortList is permitted.
A <I>PortList</I> can be followed by "/<I>methodList</I>" which restricts
available methods in the protocol.
A pseudo method "readonly" is used to prohibit methods for modification.
For example, REMITTABLE="ftp//readonly" make a FTP-DeleGate be
"read only" which inhibits uploading to FTP servers.
<P>
Protocol Specific Default:<UL>
<DL>
<DT>generalist-DeleGate
<DD>REMITTABLE="*" --
any protocol is remittable
<DT>HTTP-DeleGate
<DD>REMITTABLE="http,https/{80,443},gopher,ftp,wais"
-- usual protocols expected to be relayed by HTTP-proxies
<DT>Telnet-DeleGate
<DD>REMITTABLE="telnet/23" --
restricted to be accessible only toward standard Telnet port (23).
This restriction can be disarmed by specifying like REMITTABLE="telnet".
</DL>
</UL>
<P>
Exception:
<UL>When the current destination server is determined by
a MOUNT parameter like
MOUNT="<I>Path1</I> <I>Proto</I>://<I>Server</I>/<I>Path2</I>",
the protocol <I>Proto</I> is automatically allowed as a destination
protocol with <I>Server</I>, regardless of REMITTABLE restriction.</UL>
<P>
If the first member of a list is "+", it means the default list of
permitted protocols.  For example, REMITTABLE="+,-https/80,-wais,file"
with SERVER=http means REMITTABLE="http,https/443,gopher,ftp,file".
<BR>
<A NAME=SSLtunnel>
Note that "https" implies that non-HTTPS protocol on the SSLtunnel may
be detected and rejected.
If arbitrary protocol is to be relayed on the SSLtunnel,
specify "ssltunnel" instead of "https" like REMITTABLE="+,ssltunnel".
</A>
</UL>
</A>


<A NAME=REACHABLE>
<PRE>
REACHABLE parameter* ==  REACHABLE=<I>dstHostList</I>
                    --  default: REACHABLE="*" (any host is reachable)
</PRE>
<UL>
Only requests directed to the servers on the hosts (or networks)
listed in <I>dstHostList</I> will be accepted by the DeleGate.
When you use <A HREF=#multiRELIABLEs>multiple</A> REACHABLE parameters,
you must be certain of the meaning.
</UL>
</A>


<A NAME=RELIABLE>
<PRE>
RELIABLE parameter* ==  RELIABLE=<I>srcHostList</I>
                    --  default: RELIABLE="<A HREF="#localnet">.localnet</A>"
</PRE>
<UL>
Only requests sent from clients on hosts (or networks)
listed in <I>srcHostList</I>
will be accepted by the DeleGate.
By default, only accesses from client hosts on networks
local to the host of the DeleGate (.localnet)
are permitted.

<P>
<A NAME=multiRELIABLEs TITLE="multiple RELIABLEs">
Note that multiple RELIABLE parameters like
RELIABLE=<I>Hosts1</I> RELIABLE=<I>Hosts2</I> will be interpreted
being simply concatenated into a single RELIABLE="<I>Hosts1</I>,<I>Hosts2</I>",
which will NOT mean "<I>Hosts1 or Hosts2</I>"
if <I>Hosts1</I> or <I>Hosts2</I> includes some
<A HREF="#HostListNegation">negation</A> or
<A HREF="#HostListComposite">composite</A> operators.
You are recommended to use multiple PERMIT parameters instead
if you are not sure what does these mean.
</A>
</UL>
</A>

<A NAME=RELAY>
<PRE>
RELAY parameter*    ==  RELAY=<I>relayTypeList</I>[:<I>connMap</I>]
     <I>relayTypeList</I>  ==  <I>relayType</I>[,<I>relayType</I>]*
         <I>relayType</I>  ==  proxy | delegate | vhost | no | nojava | noapplet
           <I>connMap</I>  ==  <I>ProtoList</I>:<I>dstHostList</I>:<I>srcHostList</I>
                    --  default: RELAY="delegate,nojava:*:*:.localnet"
                                 RELAY="vhost,nojava:http:{*:80}:.localnet"
                                 RELAY="proxy:*:*:*"
</PRE>
<UL>
This parameter controls in which way the DeleGate works as a HTTP server.
DeleGate as a HTTP proxy server works in two ways (proxying modes):
as a standard (CERN compatible) HTTP proxy which accepts full URL
in a request ("proxy" <I>relayType</I>),
and as a DeleGate original proxy which accepts
<A HREF="#DGproxy">/-_-<I>URL</I></A> in a request
and rewrites URLs in the response ("delegate" <I>relayType</I>).
In a full specification format with ":<I>connMap</I>",
available proxying modes
can be classified by combination of server protocol, server host and
client host.
<P>
RELAY="no" means working as an origin HTTP server without relaying 
(Origin HTTP server is a usual server which accepts requests in usual
format, not in format for proxies, that is URL in request is neither
in full format nor in "/-_-" format, but in absolute format).
<P>
So called "transparent-proxy" ability is enabled by "RELAY=vhost".
RELAY="vhost" can be used for origin HTTP server with relaying to arbitrary
virtual hosts.  This option enables a HTTP request to be forwarded to
arbitrary destination server, indicated in "Host:" field in request header,
without explicit MOUNT.  This automatic relaying is done only when the
request URL is not MOUNTed, thus is not so likely because most DeleGate
working as origin server have MOUNT parameter for the root URL ("/*").

<P>
<A NAME=RELAY-nojava>
<P>
With "nojava" combined with other <I>relayType</I>, &lt;APPLET&gt;,
&lt;EMBED&gt; and &lt;OBJECT&gt; tags relayed in the <I>relayType</I>
will be disabled (being replaced with &lt;killed-<I>TagName</I>&gt;).
With "noapplet", only &lt;APPLET&gt; tags are disabled.
When the <I>relayType</I> "delegate" is enabled by a RELAY parameter,
using "nojava" like the default shown above is strongly recommended.
</A>

<P>
Example:
<KBD>
<UL>
    RELAY=no             ... do not work as a proxy (origin server only)
<BR>RELAY=proxy          ... CERN compatible mode only
<BR>RELAY=delegate       ... DeleGate mode only (/-_-URL)
<BR>RELAY=proxy,delegate ... both CERN and DeleGate mode
<BR>RELAY=proxy,noapplet ... inhibit &lt;APPLET&gt; tag to be relayed by proxy
</UL>
</KBD>
<P>
Default:
<UL>
Both "proxy" and "delegate" modes are allowed to users on ".localnet",
while only "proxy" mode is allowed to other users.
</UL>
</UL>
</A>


<A NAME=SCREEN>
<PRE>
SCREEN parameter ==  SCREEN={reject|accept}
                    --  default: none
</PRE>
<UL>
This parameter enables dynamically updating the black/white list for
screening clients without restarting DeleGate.
SCREEN overrides other access control specified by RELIABLE or PERMIT.
In combination with "-Eri" option, the screening is done without starting
the interpritation of the application layer protocol.
"reject" indicates forbidding only client hosts listed in the list, while
"accept" indicates allowing only client hosts listed in the list.
The list is given as a text file including an IP-address or a MAC-address
per line.
With SCREEN="reject", the text file DGROOT/etc/hosts.d/reject.txt is seen.
With SCREEN="accept", the text file DGROOT/etc/hosts.d/accept.txt is seen.
<BR>
Note: the arp command must be available by your DeleGate to use MAC-address
based screening.
</UL>
</A>


<A NAME=AUTH>
<PRE>
AUTH parameter*     ==  AUTH=<I>what</I>:<I>authProto</I>:<I>who</I>
                    --  default: none
</PRE>
<UL>
Authorize <I>who</I> to do <I>what</I>.
Authentication of user will be done using protocol specified in
<I>authProto</I>.
Identification about "<I>who the client's user is</I>"
is done based on Identification protocol to the client host
if it supports the protocol.
Otherwise FTP-server may be used as an authentication server.
<P>
In HTTP-DeleGate, user declares "<I>who am i</I>" giving an
Authorization header (in request message), which consists of
<I>Username</I>:<I>Password</I>,
where <I>Username</I> can be in a form of <I>User</I>@<I>Host</I>.
<BR>
Given a set of <I>User</I>, <I>Host</I> and <I>Password</I>,
DeleGate tries to login to the (FTP) server on <I>Host</I>
with <I>User</I> and <I>Password</I>.
If succeed, then the client is authenticated to be
<I>User</I>@<I>Host</I>.
<P>
Currently following categories of authentication/authorization
are supported:
<P>
-- in any protocol DeleGate --
<P>
<DL>
<P>
<A NAME=AUTH_admin TITLE="Remote administration">
<P>
<DT>AUTH="admin[:<I>authServ</I>[:[<I>listOfUsers</I>][:<I>listOfHosts</I>]]]"
<DD>
Enables the remote configuration and administration of DeleGate via
HTTP (or HTTPS) at "http://<I>delegateHost</I>:<I>Port</I>/-/admin/".
It allows a user to do remote administration
if the user is authenticated with <A HREF=#authServ><I>authServ</I></A>,
and if the user is in <I>listOfUsers</I>.  For example,
<KBD>AUTH=admin:-pam:<I>user</I></KBD> authorizes the <I>user</I> if
authenticated with PAM.
<KBD>AUTH=admin</KBD> is the abbreviation of <KBD>AUTH="admin:-pam:%O"</KBD>
where "%O" represents the owner of this DeleGate process.
Empty <I>authServ</I> as
<KBD>AUTH=admin::<I>user</I>:<I>pass</I></KBD> means authorizing
the username <I>user</I> with password <I>pass</I>.
If ":<I>listOfHosts</I>" is specified, users to be authorized must access
from a client hosts in the list.
<BR>
A DeleGate of arbitrary protocol (regardless of SERVER=<I>protocol</I>)
can have a port for remote administration
by specifying a port devoted to administration with "/admin" modifier like
"-P<I>userPort</I>,<I>adminPort</I>/admin" option.
<BR>
Example:<UL>
<KBD>SERVER=pop -P110,9110/admin AUTH=admin::admin:<I>password</I></KBD><BR>
The URL for remote administration of this DeleGate (as a POP proxy) is
"https://<I>delegateHost</I>:9110/-/admin/"
</UL>
</DD>
</A>
</DL>
<P>
-- in FTP server and FTP/HTTP gateway --
<P>
<DL>
<DT>AUTH="anonftp:*:<I>passWord</I>"
<DD>If specified, A DeleGate forwards E-mail address of a client's user
(which is declared by the user) to the target FTP server as an
anonymous password.
Without this AUTH, HTTP-DeleGate will send ADMIN's E-mail address
by default.
<BR>
The E-mail address must be in the form of <I>user</I>@<I>host</I>,
otherwise (if the <I>host</I> part is not given) the FTP login is
rejected by DeleGate.
<BR>
HTTP-DeleGate asks anonymous users to declare his/her E-mail address
as <I>Username</I> part in Authorization.
If <I>passWord</I> field is specified as "*" (i.e. AUTH="anonftp:*:*"),
then any <I>Password</I> in the Authorization will be acceptable.<BR>
In FTP-DeleGate, the E-mail address must be given as a password (in PASS
command) for the anonymous user, and the password is used for matching
with <I>passWord</I> too.
<BR>
The second field must be "*" in current implementation.
</DD>

<P>
<A NAME=smtp-vrfy TITLE="verifying E-mail address">
<DT>AUTH="anonftp:smtp-vrfy:*"
<DD>If specified, DeleGate verifies (using the SMTP protocol) the validity
of E-mail address given by anonymous users.
In HTTP-DeleGate, the E-mail address must be given as <I>Username</I>
part in Authorization.
In FTP-Delegate, it must be given as a password for the anonymous
user.
With this AUTH, invalid E-mail addresses can be rejected.
When the address is valid but is in a format like "<I>user</I>@<I>host</I>",
it will be expanded automatically to a FQDN format like
"user@host.domain".<BR>
If the third field is "-" (i.e. AUTH="anonftp:smtp-vrfy:-@*")
only the connectivity to mail server at "host.domain" is checked.
</DD>
</A>
</DL>
<P>
-- in proxy and origin HTTP server --
<P>
<DL>
<DT>AUTH=proxy:{ident|auth|pauth}
<DD>Specify identification/authorization protocols for the
DeleGate as a HTTP proxy server.
This parameter is checked only when access control for user
is specified in PERMIT or RELIABLE.
 <UL>
 <TABLE BORDER=0 CELLSPACING=0>
 <TR><TD>ident<TD> -- Identification protocol [default]
 <TR><TD>pauth<TD> -- Use Proxy-Authorization field "user@host:password"
 <TR><TD>auth <TD> -- Use Authorization field "user@host:password"
 </TABLE>
 </UL>
Example:<UL>
<KBD>
AUTH=proxy:auth PERMIT="*:*:{*,!?}@*"<BR>
</KBD>
// Any user at any host is allowed as long as he/she is identified.</UL>

Note:<UL>
When the client does not support Proxy-Authentication,
you are obliged to use "proxy:auth" for Authentication.
In such case, note that the client cannot access
resources which requires Authentication.</UL>
</DL>
<P>
In the case where the FTP-server based authentication is used, 
a recommended user name of the authorization information is
e-mail address like "<I>user</I>@<I>host</I>.<I>domain</I>"
so that it can be commonly used for both AUTH="anonftp" and AUTH="proxy".
</UL>
</A>

<A NAME=AUTHORIZER>
<PRE>
AUTHORIZER parameter* ==  AUTHORIZER=<I>authServList</I>[@<I>realmValue</I>][:<I>connMap</I>]
       <I>authServList</I>  ==  [<I>authForw</I>,]<I>authServ</I>[,<I>authServ</I>]* | & | *
           <I>authForw</I>  ==  -map{<I>inPat</I>}{<I>localPat</I>}{<I>fwdPat</I>} | -strip | -fwd
           <I>authServ</I>  ==  <I>authHost</I>[/<I>portNum</I>][(<I>reprUser</I>)]
           <I>authHost</I>  ==  <I>hostName</I> | <I>hostAddr</I>
         <I>realmValue</I>  ==  word | {words separated with space}
            <I>connMap</I>  ==  <I>ProtoList</I>:<I>dstHostList</I>:<I>srcHostList</I>
                    --  default: none
                    --  restriction: applicable to Telnet, FTP, NNTP, SMTP, IMAP,
                                     Socks, SockMux, and HTTP
</PRE>
<UL>
Specify the server for authentication and authorization ("auth-server").
If specified, an access by a client is not permitted without
authenticated successfully by the auth-server,
sending an appropriate pair of user-name and pass-word
over the application protocol.
Two special <I>authServ</I> "-none" and "-never" are exceptions
to make authentication unnecessary.
If <I>authServ</I> is followed by "(<I>reprUser</I>)", the users 
successfully authenticated in the <I>authServ</I> are represented by
<I>reprUser</I> as a representative user.
<P>
Note that even a client authorized by an auth-server is not permitted
if the client's host does not pass other access controls
(<A HREF=#RELIABLE>RELIABLE</A> and <A HREF=#PERMIT>PERMIT</A>).
To permit any authorized client regardless of its host, specify as
RELIABLE="<A HREF=#iType>-a/</A>*". Also RELIABLE="*" works for this purpose
but is not safe on modifications of configuration and DeleGate.
<P>
Adding <I>connMap</I>, an auth-server can be selected conditionally on
a combination of destination protocol, server host and client host.
The <I>authServList</I> is a host name of authentication server, or a
list of host names of authentication servers.
If <I>authServList</I> is followed with "@<I>realmValue</I>", the value is
used to define the realm of protection space in HTTP-DeleGate.
It can be overridden by MountOption "realm=realmValue" for each MOUNT point.
<P>
Currently, the default protocol of remote authentication/authorization server
is that of FTP protocol with USER and PASS commands.  Thus any real FTP
server can be used as an authentication/authorization server of DeleGate.
Another way of maintaining DeleGate's own lists for
authentication/authorization is using
<A HREF="#func_auth">-Fauth</A> function.
<P>
<A NAME=authServ>
There are built-in auth-servers to be used as <I>authServ</I> as follows:
<UL>
<DL>
<DT><KBD>-none</KBD>
 -- allow without caring if authentication is given or not
<DT><KBD>-never</KBD>
 -- disallow without careing if authentication is given or not
<DT><KBD>-any</KBD>
 -- any combination of username + password is acceptable
<DT><KBD>-anonftp</KBD>
 -- username is "ftp" or "anonymous" and password includes "@"
<DT><KBD>-dgauth<I>[</I>.<I>realm</I><I>]</I></KBD>
 -- password is sent safely as a digest (HTTP and APOP)
<DT><KBD>-pam/<I>service</I></KBD>
 -- username + password is checked by PAM
<DT><KBD>-list{<I>user</I>:<I>pass</I>,...}</KBD>
 -- the pair of username and password is in the list
<DT><KBD>-userpass/<I>user</I>/<I>pass</I></KBD>
 -- equivalent to <KBD>-list{<I>user</I>:<I>pass</I>}</KBD>
<DT><KBD>-hostlist/<I>ListName</I></KBD>
 -- client's host is in the HOSTLIST=<I>ListName</I>:<I>HostList</I>
<DT><KBD>-fail.badpass</KBD>
 -- disallow if the username exists but password is wrong
<DT><KBD>-fail.nopass</KBD>
 -- disallow if password is not given or empty
<DT><KBD>-cmd{<I>cmd</I> <I>arg</I> ...}{<I>ENV</I>=<I>val</I> ...}</KBD>
 -- external command for authentication
<DT><KBD>-ntht</KBD>
 -- NTLM over HTTP (Win32 only)
<DT><KBD>-login</KBD>
 -- logon to the local host (Win32 only)
<DT><KBD>-man</KBD>
 -- manual authentication on demand
</DL>
</UL>

<DL>
<A NAME=dgauth>
<P>
<DT>DGAuth: <KBD>-dgauth[.<I>realm</I>][{<I>user</I>:<I>pass</I>,...}]</KBD><BR>
<DD>Authentication scheme based on digested password, specific to each
application protocol, is enabled with "AUTHORIZER=-dgauth".
This kind of authentication scheme,
at least APOP proxy or HTTP Digest/Basic gateway does,
requires the original cleartext of password.
A simple way to do so is giving directly a list of pairs of username
and password as
<KBD>-dgauth{<I>user1</I>:<I>pass1</I>,<I>user2</I>:<I>pass2</I>,...}</KBD>.
Another way is storing passwords by DeleGate with
<KBD>"-Fauth -a <I>username</I>:<I>password</I> -dgauth"</KBD>.
Since passwords for -dgauth is stored in encrypted form, a keyword is
required for the encryption.
Specify the keyword as CRYPT=pass:<I>keyword</I>
or answer it interactively afterwards.
Otherwise, DGAuth can be delegated to a remote
<A HREF=#serv_DGAuth>DGAuth server</A>.
DGAuth generates a session identifier which is retained identically
during the session started by an authentication,
then passed to CFI/CGI programs in environment variable "X_DIGEST_SESSION"
and can be logged into <A HREF=#http_session_log>PROTOLOG</A>.
<P>
Example:
<UL>
// a HTTP proxy or server with the Digest authentication with clients.<BR>
<KBD>SERVER=http AUTHORIZER=-dgauth</KBD><BR>
// a POP proxy which uses APOP authentication with clients.<BR>
<KBD>SERVER=pop MOUNT="* pop://server/*" AUTHORIZER=-dgauth</KBD><BR>
</UL>
</DD>
</A>

<P>
<DT>PAM: <KBD>-pam[/<I>service</I>]</KBD><BR>
<DD>On platforms where PAM (Pluggable Authentication Modules) is available,
it can be used for authentication with the syntax
<KBD>AUTHORIZER="-pam/<I>service</I>"</KBD>,
for example as AUTHORIZER="-pam/passwd", AUTHORIZER="-pam/ftp" and so on.
<BR>
Note that most of PAM authentications need to be executed under the
privilege of superuser on Unix (with OWNER="root" option).
But you can avoid running your DeleGate with superuser privilege by
installing external program "dgpam" under <A HREF=#subin>DGROOT/subin/</A>.
Also PAM authentication can be delegated to a remote
<A HREF=#serv_PAM>PAM server</A>.
<P>

<DT>LIST: <KBD>-list{<I>user</I>[:<I>pass</I>],...}</KBD><BR>
<DD>An element of the list can be <I>user</I> only without ":<I>pass</I>"
which means matching <I>user</I> name only and don't care the password.
In the "-list{<I>user</I>:<I>pass</I>,...}", substitution by
"<A HREF=#aging>[date+<I>format</I>]</A>"
can be used in <I>user</I> and <I>pass</I>.
For example, AUTHORIZER="-list{guest:[date+%y%m]}" means accepting
usrename "guest" with password "0405" in May 2004.
<P>
Example:
<UL>
<KBD>AUTHORIZER="-list{u1:p1,u2:p2}(local),-pam,-none(anonymous)"</KBD>
<BR>
// a user may be authenticated as "local" or as some user name in PAM,<BR>
// or "anonymous" otherwise<BR>
</UL>

<P>
<DT>CMD: <KBD>-cmd{<I>cmd</I> <I>arg</I> ...}[{<I>ENV</I>=<I>val</I> ...}[{<I>input-pattern</I>}]]</KBD>
<DD>
Do the authentication with an external command <I>cmd</I>.
Values to be used the authentication to be passed to the command is
specified with the format as "%<A HREF=#authgen>format</A>"
like <KBD>%U</KBD> for username and <KBD>%P</KBD> for password.
A parameter can be passed in command-line argument,
in environment variable or in the standard input of the command.
If the environment and <I>input-pattern</I> is omitted as
<NOBR><KBD>AUTHORIZER="-cmd{<I>cmd</I>}</KBD></NOBR>,
the pair of user name and password is passed by default
as if implicitly specified as
<NOBR><KBD>AUTHORIZER="-cmd{<I>cmd</I>}{DG_USER=%U DG_PASS=%P}{USER %U\nPASS %P\n}</KBD>".</NOBR>
<P>
The result of the authentication by the command is shown in its output string
or by its exit code.
The command may puts a string to its standard output to show the result
in the form of a status response of the FTP protocol, that is,
"230" for success and "530" for failure.
Otherwise the exit code of the process is used, the value zero for success
and non-zero values for failure.
<P>
Example: passing username in argument while password in environment variable
<UL>
<KBD>AUTHORIZER="-cmd{myauth %U}{MYPASS=%P}"</KBD>
<P>
[the content of the <KBD>myauth</KBD> command]
<BR>
<KBD>
#!/bin/sh<BR>
if [ "$1" = "user1" -a "$MYPASS" = "pass1" ]; then<BR>
&nbsp; echo "230 SUCCESS"<BR>
else<BR>
&nbsp; echo "530 FAILURE"<BR>
fi<BR>
</KBD>
</UL>
<DD>

</DL>
</A><!-- authServ -->

<A NAME=authForw>
<DL>
<DT>
AUTHFORW: <KBD>-map{<I>inPat</I>}{<I>localPat</I>}{<I>fwdPat</I>} | -strip | -fwd</KBD><BR>
<DD>
(available only in FTP and POP currently)<BR>
The "-map" prefix is used to split incoming authentication information
of USER and PASS (in <I>inPat</I> pattern) into a pair of authentications,
the one to be used locally by <I>authServList</I> (in <I>localPat</I>) and
another to be forwarded to the server (in <I>fwdPat</I>).
Each authentication information to be matched or generated is represented
by a string of a pair of a user name and a password as
"<I>username</I>:<I>password</I>".
If the username string generated by <I>fwdPat</I> ends with a substring as
"@<I>Host</I>" then it is striped and the <I>Host</I> is used as
the destination server.
The string is matched and generated by the pattern specification format
common to the one used for pattern matching in the
<A HREF=#MountComplex>MOUNT</A> parameter.

<BR>
Example: -strip<UL><DL>
 <DT><KBD>1A) AUTHORIZER="-map{%S@%S:%S@%S}{%(0):%(2)}{%(1):%(3)},-list{u1:p1},-pam"</KBD><BR>
 <DT><KBD>1B) AUTHORIZER="-strip,-list{u1:p1},-pam"</KBD>  ## equiv. to the above<BR>
 <DD>incoming auth. <-- USER user1@user2@host2 + PASS pass1@pass2<BR>
     local auth. by u1 or PAM <-- USER user1 + PASS pass1<BR>
     outgoing to the server h2 <-- USER user2 + PASS pass2
</DL></UL>
Example: -fwd<UL><DL>
 <DT><KBD>2A) AUTHORIZER="-map{%S:%S}{%S:%S}{%S:%S},-list{u1:p1},-pam"</KBD><BR>
 <DT><KBD>2B) AUTHORIZER="-fwd,-list{u1:p1},-pam"</KBD>  ## equiv. to the above<BR>
</DL></UL>
Example: <UL><DL>
 <DT><KBD>3A) AUTHORIZER="-map{%S}{%S}{},-list{u1:p1},-pam"</KBD><BR>
 <DT><KBD>3B) AUTHORIZER="-list{u1:p1},-pam"</KBD>  ## equiv. to the above<BR>
</DL></UL>

As shown in the above example 1),
<KBD>"-strip"</KBD> is used to support a nested username and password
as USER "u1@u2@u3@h3@h2@h1" and PASS "p1@p2@p3".
It strips the first element before '@' in the USER and PASS to be used
for local authentication, strips the last element after '@' in USER as
the destination server, then forwards remaining string
to the destination server.
<KBD>"-fwd"</KBD> specifies to use the same USER and PASS both for the
local authentication and the authentication with a server.
</DL>
</A><!-- authForw-->


<P>
If only authentication of user is necessary without authorization,
the following special name will be useful as a <I>authServList</I>.
<P>
<UL>
"&" -- the client host (user name on the client host is required)<BR>
"*" -- any <I>authHost</I> specified by the client as "<I>user</I>@<I>authHost</I>"
</UL>
<P>
Example:
<UL>
// clients from outside of local.domain is required authentication<BR>
<KBD>
SERVER=telnet AUTHORIZER="&:::!*.local.domain"<BR>
</KBD>
// any clients is allowed if the user is authenticated with localhost<BR>
<KBD>
SERVER=telnet AUTHORIZER="localhost" RELIABLE="*"<BR>
</KBD>
// using DeleGate's own list of "-socksusers" maintained with
"<A HREF=#func_auth>-Fauth</A>"<BR>
<KBD>
SERVER=socks AUTHORIZER=-socks.users
</KBD>
</UL>
</UL>
</A>


<A NAME=MYAUTH>
<PRE>
MYAUTH parameter*   ==  MYAUTH=<I>username</I>:<I>password</I>[:<I>connMap</I>]
                    --  default: none
                    --  restriction: applicable to Socks, VSAP, SMTP, and HTTP
</PRE>
<UL>
Specify authorization information to be sent to an upstream server/proxy.
Special characters in <I>username</I> or <I>password</I> must be escaped
with "%<I>XX</I>" where <I>XX</I> is hexadecimal representation of
a character code (see ascii(7)).
Special characters to be escaped are:
TAB ("%09"), SPACE ("%20"), '"' ("%22"), '%' ("%25"), ':' ("%3A"),
'{' ("%7B"), and '}' ("%7D").
<P>
The pair of username+password which is sent from a client can be forwarded
to the server by MYAUTH="<A HREF=#authgen>%U:%P</A>"
(supported in HTTP and FTP only).
<P>
NOTE:
For authentication with proxies, it is strongly recommended to use
<A HREF=#FORWARD>FORWARD</A> with a gateway-URL including
authentication information instead of MYAUTH.
For example,
<KBD>SOCKS=host:port</KBD> with <KBD>MYAUTH=user:pass</KBD>
can be represented as
<KBD>FORWARD=socks://user:pass@host:port</KBD>.
<P>
Example:<UL>
<KBD>
MYAUTH=userS:passS:socks<BR>
MYAUTH=userV:passV:vsap<BR>
MYAUTH=userM:passM:smtp:smtpserverM<BR>
MYAUTH=userH:passH:http:httpserverH<BR>
MYAUTH=userP:passP:http-proxy:httpproxyP<BR>
</KBD>
</UL>
</UL>
</A>


<A NAME=RIDENT>
<PRE>
RIDENT parameter    ==  RIDENT=<I>ridentType</I>[,<I>ridentType</I>]*
       <I>ridentType</I>   ==  client | server
                    --  default: none
</PRE>
<UL>
If RIDENT="server" is specified, identification information about the
client socket got by getsockname(2) and getpeername(2) will be
forwarded to the PROXY or MASTER-DeleGate which will receive the
information by RIDENT="client", and will use it for access control.
A DeleGate server with RIDENT="client" can accept both from DeleGate
with RIDENT="server" and other proxy servers with no RIDENT support.
An intermediate DeleGate in a chain of cascaded DeleGate servers
should be given RIDENT="client,server".
<P>
Example:<UL>
<KBD>
<I>host1</I># delegated -P8080 RIDENT=server MASTER=<I>host2</I>:8080<BR>
<I>host2</I># delegated -P8080 RIDENT=client
</KBD>
</UL>
</UL>
</A>


<A NAME=MAXIMA>
<PRE>
MAXIMA parameter*   ==  MAXIMA=<I>what</I>:<I>number</I>,...
                    --  default: MAXIMA=listen:20,ftpcc:2,...
</PRE>
<UL>
Specify the maximum number of resource usage, processes, connections, etc.
<P>
<UL>
<TABLE BORDER=0 CELLSPACING=0>
<TR><TD><A HREF="#defense">randstack</A><TD> -- <TD>randomization range of stack base for security [32]
<TR><TD>randenv  <TD>--<TD> randomization range of environment variables base [1024]
<TR><TD>randfd   <TD>--<TD> randomization range of client socket file-descriptor [32]
<TR><TD>listen   <TD>--<TD> max. size of the queue for <A HREF="#entrance">entrance</A> port [20]
<TR><TD>delegated<TD>--<TD> max. number of DeleGate processes runnable at a time [64]
<TR><TD>service <TD>--<TD> max. number of services per delegated process [unlimited]
<TR><TD>standby  <TD>--<TD> max. number of standby process [32]
<TR><TD>conpch   <TD>--<TD> max. number of connections at a time per client host [unlimited]

<TR><TD>ftpcc   <TD>--<TD> max. number of FTP connection cache servers to a host [16]
<TR><TD>nntpcc  <TD>--<TD> max. number of NNTP connection cache processes to a host[16]
<TR><TD>http-cka <TD>--<TD>
(replaced by HTTPCONF=<A HREF="#max-cka">max-cka)</A>
<TR><TD>http-ckapch<TD>--<TD>
(replaced by HTTPCONF=<A HREF="#max-ckapch">max-ckapch</A>)
<TR><TD>udprelay<TD>--<TD> max. number of parallel UDPrelay client [32]
<TR><TD>winmtu<TD>--<TD> max. unit of send() on Win32 [1024]
</TABLE>
</UL>
</UL>
</A>


<A NAME=TIMEOUT>
<PRE>
TIMEOUT parameter*  ==  TIMEOUT=<I>what</I>:<I>seconds</I>,...
                    --  default: TIMEOUT=dns:10,acc:10,con:10,lin:30,...
</PRE>
<UL>
Specify timeout period (in seconds by default) of <I>what</I>.
<A NAME="period-value">
The timeout value "0" means "<I>never timeout</I>" (unlimited).
The unit of period is second by default,
but can be changed like 1d(day), 1h(hour), 1m(minute).
</A>
<P>
<UL>
<A NAME=TIMEOUT-io>
<TABLE BORDER=0 CELLSPACING=0>
<TR><TD><A HREF="#defense">shutout</A>  <TD> -- <TD> disarming emergent shutout set on fatal error [1800]
<TR><TD>dns    <TD> -- <TD> for DNS lookup [10]
<TR><TD>dnsinv <TD> -- <TD> for DNS inverse lookup [6]
<TR><TD>nis    <TD> -- <TD> for NIS lookup [3]
<TR><TD>acc    <TD> -- <TD> for accept from client (include FTP data connection) [10]
<TR><TD>con    <TD> -- <TD> for connection to the server [10]
<TR><TD>lin    <TD> -- <TD> LINGER for output [30]
<TR><TD>authorizer<TD> -- <TD> expiration of authorization by <A HREF=#AUTHORIZER>AUTHORIZER</A> [unlimited]
<TR><TD>dgnonce <TD> -- <TD> for AUTHORIZER=<A HREF=#dgauth>-dgauth</A> (lifetime of "nonce") [60]
<TR><TD>ident  <TD> -- <TD> for connection to Ident server [1]
<TR><TD>rident <TD> -- <TD> for receiving <A HREF=#RIDENT>RIDENT</A>=client info. [1.0]
<TR><TD>io     <TD> -- <TD> general I/O (no data transmission) [600]
<TR><TD>silence<TD> -- <TD id=wrap> no data transmission either from client or server [0]
(applicable only to <A HREF="#serv_tcprelay">tcprelay</A>)
<TR><TD>hello  <TD> -- <TD> for HELLO negotiation with the MASTER [30]
<TR><TD>login  <TD> -- <TD> for login to proxy (Telnet,FTP,SOCKS) [60] 
<TR><TD>daemon <TD> -- <TD> delegated [unlimited]
<TR><TD>restart<TD> -- <TD> cause <A HREF="#RESTART">restart</A> at every specified period [unlimited] 
<TR><TD>standby<TD> -- <TD> keep the delegated alive on standby for next client [30]
<TR><TD>takeover<TD> -- <TD id=wrap> taking over a downloading to cache after client's disconnection [5]
<BR>(after the disconnection of the client which initiated the downloading)
<TR><TD>ftpcc  <TD> -- <TD> for keeping alive FTP Connection Cache [120]
<TR><TD>nntpcc <TD> -- <TD> for keeping alive NNTP Connection Cache [300]
<TR><TD>http-cka<TD> -- <TD>
(replaced by HTTPCONF=<A HREF="#tout-cka">tout-cka</A>)
<TR><TD>cfistat<TD> -- <TD> for status information from
                            <A HREF="#cfistat">-s</A>,filter [1.0]
</TABLE>
</A>
</UL>
</UL>
</A>


<A NAME=DELAY>
<PRE>
DELAY parameter*    ==  DELAY=<I>what</I>:<I>seconds</I>
                    --  default: DELAY=reject:60,unknown:60,...
</PRE>
<UL>
Delay for specified seconds before doing <I>what</I>.
<P>
<UL>
<TABLE BORDER=0 CELLSPACING=0>
<TR><TD>reject    <TD> -- <TD> continuous Reject resp. from self or MOUNTed servers [60]
<TR><TD>unknown   <TD> -- <TD> continuous Unknown resp. from self or MOUNTed servers [60]
<TR><TD>reject_p  <TD> -- <TD> continuous Reject resp. from origin server [0]
<TR><TD>unknown_p <TD> -- <TD> continuous Unknown resp. from origin server [0]
</TABLE>
</UL>
<P>
Each value specifies the maximum delay time and delay time increases
according as the error count increases.
</UL>
</A>


<A NAME=MOUNT>
<PRE>
MOUNT parameter*    ==  MOUNT="<I>vURL</I> <I>rURL</I> [<I><A HREF="#MountOptions">MountOptions</A></I>]"
                    --  default: MOUNT="/* <I>SERVER_URL</I>*"
</PRE>
<UL>
Map <I>vURL</I> to/from the <I>rURL</I>.
URLs matches with <I>vURL</I> in a request message from a client
are rewritten to <I>rURL</I> and forwarded to a server, and
URLs matches with <I>rURL</I> in a response message from the server
is rewritten to <I>vURL</I> and forwarded to the client.
What is rewritten by MOUNT in each protocol is like follows: 
<UL>
<DL>
<DT><A HREF=#HTTP_mount>HTTP</A> -- URL or part of it appeared in header or HTML body (tags)
<DT><A HREF=#FTP_MOUNT>FTP</A> -- file name in command and status response
<DT><A HREF=#NNTP_mount>NNTP</A> -- newsgroup name in command, status response, and user data (header)
<DT>POP -- user and host name in USER,PASS,APOP command
<DT>IMAP -- user and host name in LOGIN command
<DT>SMTP -- mail address in the RCPT command
<DT>Telnet -- hostname and port number of destination server
<DT><A HREF=#LDAP_MOUNT>LDAP</A> -- base object name in requests/responses
</DL>
</UL>

<P>
If a <I>vURL</I> is terminated with "*"
then partially matched path is also rewritten.
If a <I>rURL</I> is terminated with "*" then remaining part
in the partially matched path will be copied after the <I>rURL</I>.
<P>
Example: a MOUNT for HTTP-DeleGate
<UL>
<KBD>
MOUNT="/abc/* http://<I>host</I>/*"<BR>
</KBD>
// rewrites "/abc/def" to/from "http://<I>host</I>/def"
</UL>
<P>
If "=" is specified as <I>vURL</I> or <I>rURL</I>,
it means mount <I>as is</I> without
rewriting for the <I>vURL</I> in a request,
or rewriting for <I>rURL</I> in a response.
<P>
The port number of the destination server (in <I>rURL</I>)
can be prefixed with "-" or "+"
to be determined dynamically
by offsetting from the port number of the entransport,
as in <A HREF="#portmap">SERVER</A> parameter.

<A NAME="odst.-">
<P>
A special host name <KBD>"odst.-"</KBD> in <I>rURL</I> (or in the SERVER
parameter) represents the original destination host of the TCP connection
from the client via NAT (provided by iptables on Linux).
It can be used to configure a transparent proxy (or gateway)
for arbitrary protocols.
The original destination port number can be referred with "-" as "odst.-:-".
The number can be mapped with an offset value as "-8000" or "+8000" for example.
The name "odst.-" can be used in the "<A HREF=#nvserv>rserv</A>" MountOption
too.
</A>
<P>
If the <I>rURL</I> is of "file:<I>path</I>" and the <I>path</I> is
a relative one, then the data file is searched under the
<A HREF="#DGROOT">DGROOT</A> directory or directories listed in
<A HREF="#DATAPATH">DATAPATH</A>.
<P>
If a <I>rURL</I> is prefixed as "<KBD>vurl:</KBD><I>rURL</I>", the rewritten
URL (in a request message) from <I>vURL</I> to <I>rURL</I> will be
rewritten by another MOUNT again.
This recursive MOUNT is not applied to the rewriting a URL in response data
from <I>rURL</I> to <I>vURL</I>,
therefore it does not work as expected in HTTP where such reverse rewriting
of URL in response is expected too.
<P>
Example: recursive MOUNT
<UL>
<KBD>
MOUNT="/x/* vurl:/f/x/*"<BR>
MOUNT="/y/* vurl:/f/y/*"<BR>
MOUNT="/f/* ftp://server/*"<BR>
</KBD>
// "<KBD>/x/path</KBD>" is rewritten to "<KBD>ftp://server/x/path</KBD>"<BR>
// "<KBD>ftp://server/x/path</KBD>" is rewritten to "<KBD>/f/x/path</KBD>"<BR>
</UL>

<A NAME=MountAbbrev TITLE="Abbreviations">
<P>
<B>Abbreviations</B>
<P>
To make configurations be simple and reusable, special abbreviated
formats of URL can be used in MOUNT parameter.
If "=" is specified as <I>protocol-name</I>, <I>host-name</I>
or <I>port-number</I> in <I>rURL</I> which consists of
<I>protocol-name</I>://<I>host-name</I>:<I>port-number</I>/<I>url-path</I>,
then it represents that of the DeleGate itself (i.e. that of <I>vURL</I>).
URLs beginning with "//" represents further abbreviations,
"///<I>path</I>" for "=://=:=/<I>path</I>" (in the same protocol,host and port)
and
"//<I>serv</I>..." for "=://<I>serv</I>..." (in the same protocol).
<P>
Abbreviated <I>host-name</I> and <I>port-number</I> is substituted by
that of the virtual host (given in HTTP Host: field) if exists,
or by that of the real interface with the client.
To explicitly specify the real interface, use "-P" for
"<I>host-name</I>:<I>port-number</I> part like "http://-P/<I>path</I>".
<P>
Example: abbreviation in <I>rURL</I> of MOUNT parameter
<UL>
// DeleGate's parameters: SERVER=http -Pdhost:9080 ... <BR>
// Requested URL:  http://vhost:9080/x/ <BR>
<KBD>
MOUNT="/x/* =://=:=/y/*"   -> http://vhost:9080/y/ <BR>
MOUNT="/x/* ///y/*"        -> (the abbreviation of the above) <BR>
MOUNT="/x/* //-P/y/*"      -> http://dhost:9080/y/ <BR>
MOUNT="/x/* =://serv/y/*"  -> http://serv:80/y/ <BR>
MOUNT="/x/* //serv/y/*"    -> (the abbreviation of the above) <BR>
MOUNT="/x/* //serv:=/y/*"  -> http://serv:9080/y/ <BR>
MOUNT="/x/* //=:9088/y/*"  -> http://vhost:9088/y/ <BR>
MOUNT="/x/* https://=/y/*" -> https://vhost:443/y/ <BR>
</KBD>
</UL>
</A>

<A NAME=MountComplex TITLE="Complex Matching and Rewriting">
<P>
<B>Complex Matching and Rewriting</B>
<P>
A pattern following "*%" in <I>vURL</I> and <I>rURL</I> represents
a pattern for complex matching specified in the format like that of scanf(3).
Each format specification consists of a specification following "%",
like "%c", "%[a-z]" and so on.
The extended format "%S" has variable meanings determined by its
adjacent character, i.e. "%S<I>x</I>" means "%[^<I>x</I>]<I>x</I>":
ex. "%S." for "%[^.]." and "%S/" for "%[^/]/".
"%(<I>N</I>)" in <I>rURL</I> means copying <I>N</I>th element in
<I>vURL</I>.
If a <I>vURL</I> pattern ends with "$" character, then complete
matching to the end of URL string is required.

<P>
Example: complex matching and rewriting
<UL>
<KBD>
// Requested URL:  http://dhost/x/abc/def <BR>
MOUNT="/x/*%S/%S     ///y/*%S.%S"     -> http://dhost/y/abc.def <BR>
MOUNT="/x/*%S/%S     ///y/*%(1)/%(0)" -> http://dhost/y/def/abc <BR>
MOUNT="/x/*%1[a-z]%S http://w/*%S/%S" -> http://w/a/bc/def <BR>
</KBD>
</UL>

</UL>
</A>
</A>


<A NAME=MountOptions>
<PRE>
MountOptions == <I>option</I>[,<I>option</I>]*
</PRE>
<UL>
MountOptions is a list of options, to make MOUNT be conditional,
or to apply some functions only to MOUNTed URLs.
Some of them are common to any protocol
and others are specific to a protocol (
<A HREF="#HTTP_mount">HTTP</A>,
<A HREF="#NNTP_mount">NNTP</A>
).
<P>
<B>CONDITIONS:</B>
<BR>
The first group of options are to make MOUNT be conditional
depending on source and destination (client and server).
When a MOUNT parameter have a <I>MountOption</I>
including one or more conditions,
the MOUNT will be ignored without all of conditions are true.
<P>
<DL>
<DT>from={<I>HostList</I>} -- from the client.
<DD>
true if the client is included in the <I>HostList</I>.

<DT>via={<I>HostList</I>} -- via the host.
<DD>
true if at least one host passed through on the way
is included in the <I>HostList</I>.

<DT>path={<I>HostList</I>} -- through the hosts.
<DD>
true if all of hosts passed through is included in the <I>HostList</I>.

<DT>auth={<I>HostList</I>} -- authorized by the host.
<DD>
true if a password based authentication succeeded with a
<A HREF=#AUTHORIZER>AUTHORIZER</A> host listed in the <I>HostList</I>.

<DT>withssl
<DD>
true if the client-side connection is encrypted with SSL or TLS

<DT>sni={<I>HostList</I>} -- name based virtual hosting based on SNI/TLS
<DD>
true if the TLS client connected to the DeleGate with the hostname
(server name indicated in TLS protocol) included in <I>HostList</I>.
</DD>

<A NAME=MountOpt_host TITLE="'host' MountOption"><P>
<DT>host={<I>HostList</I>} -- interface host with the client.
<DD>
true if the client has connected to the DeleGate via the specified network
interface included in the <I>HostList</I>.<BR>
Note that this option is applicable to any client side protocol, that is,
not only HTTP-DeleGate but also DeleGate for FTP, POP, NNTP, etc. can
switch destination server based on the client side interface if
its has an IP address distinguishable from others.<BR>
When the DeleGate is acting as an origin HTTP server and a virtual
host name is shown in "Host: host" field in the request message,
the virtual name is examined prior to the real host name. If
multiple virtual names are bound to the same IP-address,
prefix "-" to the virtual hostname like "host=-hostname" to
distinguish among virtual names.
</DD>
</A>

<A NAME=MountOpt_odst TITLE="'odst' MountOption"><P>
<DT>odst={<I>HostList</I>} -- NAT based virtual hosting
<DD>
true if the original destination of the TCP connection from the client
is included in the <I>HostList</I>.  This option is available on Linux
with NAT (by iptables) on Linux.
The original destination can be used as the real destination with a
special host name "<A HREF=#odst.->odst.-</A>".
</DD>
</A>

<DT>dst={<I>HostList</I>} -- to the server.
<DD>
true if the destination host is included in the <I>HostList</I>.
This option will be useful when "=" is used
as the right hand of MOUNT.

<DT>udst={<I>HostList</I>}
<DD>
true if the host in the site part of a full-URL (as http://site/path)
is included in the <I>HostList</I>.
This option will be used with the "referer" MountOption to rewrite URL
in the "Referer" field.

<DT>direction=<I>Direction</I> -- request or response
<DD>
true when the MOUNT parameter is applied to specified <I>Direction</I>
which is one of followings:
<DL>
<DT>fo -- apply forward (request rewriting) only
<DT>bo -- apply backward (response rewriting) only
<DT>bif -- apply backward if it was applied forward
</DL>

<DT>-f,<I>conditionList</I> -- conditions applied only in request rewriting
<DD>
<DT>-b,<I>conditionList</I> -- conditions applied only in response rewriting
<DD>
<DT>-f.<I>condition</I> -- a condition applied only in request rewriting
<DD>
<DT>-b.<I>condition</I> -- a condition applied only in response rewriting
<DD>
<DT>-x.<I>condition</I> -- a condition to be applied to both directions
<DD>
"avhost" and "nvhost" are conditions tested only in request rewriting
by default.  These conditions come to be tested also in response rewriting
by prefixing "-x." as "-x.nvhost=<I>host</I>".

<DT>pri=<I>signedFloatNumber</I> -- priority of this MOUNT parameter
<DD>a MOUNT parameter with larger priority value is tested prior to
another with lower priority.  The default priority value is zero.

<DT>nocase -- ignore character case in URL path matching
<DD>

</DL>

<P>
These <I>HostList</I> should be a list of <I>host</I>:<I>port</I>,
where :<I>port</I> part can be omitted when it is not to be cared.
The <I>host</I> part can be represented as "*"
when the difference of network interface is not to be cared.
<P>
Example:
<UL>
// switch MOUNT depending on from which interface the client is<BR>
<KBD>
MOUNT="* URL1 host=this-host"<BR>
MOUNT="* URL2 host=localhost"<BR>
</KBD>
// switch MOUNT depending on from which port the client is<BR>
<KBD>
-P70,80<BR>
MOUNT="* URL1 host=*:70"<BR>
MOUNT="* URL2 host=*:80"<BR>
</KBD>
</UL>
<P>
<B>CONTROLS</B>:
<BR>
The second group of options are to control the behaviors of DeleGate
which are local to the MOUNT point.
<P>
<DL>
<DT>public -- allow public access
<DD>do not apply any access restriction (by <A HREF="#PERMIT">PERMIT</A> etc.)
to this MOUNT point.

<DT>rident[=no] -- forward <A HREF="#RIDENT">RIDENT</A> information to server
<DD>forward (or stop forwarding) RIDENT information to the MOUNTed server
regardless of the RIDENT=server parameter.

<DT>ro -- allow read only.
<DD>applicable to NNTP (inhibit POST command) and origin FTP (default).

<DT>rw -- allow both read and write.
<DD>allow origin FTP-DeleGate to write to its local files.

<DT>cache=no -- disable cache.
<DD>disable any usage of cache for the server of this MOUNT point.
<DT>expire=<I>period</I> -- validity of cache
<DD>expire period of the MOUNT point, overriding the global
<A HREF="#EXPIRE">EXPIRE</A> parameter.

<DT>expires=<I>period</I> -- validity of each response
<DD>if specified, "Expires:" field is added into each HTTP response message.
If the <I>period</I> begins with '+' or '-', like "expire=+1d", and if
the original message has "Expires:" header, then the expire date is
relative to the original expiration date.

<DT>ftocl=<I>filterCommand</I> -- apply external filter
<DD>apply the filter to the MOUNT point,
overriding the global <A HREF="#FTOCL">FTOCL</A> parameter.

<DT>charcode=<I>charCode</I> -- code conversion.
<DD>code conversion specific to this mount point,
overriding the global <A HREF="#CHARCODE">CHARCODE</A> parameter.
</DD>

<A NAME=MOUNT_routing>
<DT>proxy=<I>host</I>:<I>port</I> -- upstream proxy server
<DT>master=<I>host</I>:<I>port</I> -- upstream MASTER-DeleGate
<DD>use an upstream proxy server for the MOUNT point,
instead of the one specified in the global
<A HREF="#MASTER">MASTER</A> or
<A HREF="#PROXY">PROXY</A> parameter.
</DD>
</A>

<DT>MAXIMA=bps:<I>speed</I> -- maximum transmission speed
<DD>choke the speed of the date transmission (HTTP and FTP) as
MAXIMA=bps:128k for example.

</DL>
</UL>
</A>


<A NAME=URICONV>
<PRE>
URICONV parameter*  ==  URICONV={<I>convSpec</I>|<I>defElem</I>|<I>defAttr</I>}
          <I>convSpec</I>  ==  <I>convList</I>:<I>attrList</I>
           <I>defElem</I>  ==  defelem:+,<I>elemnameList</I>
           <I>defAttr</I>  ==  defattr:+,<I>attrnameList</I>
                    --  default: it will be shown by URICONV=dump
</PRE>
<UL>
Specify which kind of URI rewriting should be applied to which kind
of attributes of tags in HTML document.  The <I>convList</I> is a list of
following items.
<P>
<UL>
<TABLE BORDER=0 CELLSPACING=0>
<TR><TD>mount   <TD> -- <TD>rewriting by MOUNT
<TR><TD>normal  <TD> -- <TD>normalize MOUNTed URL if it includes "../" in URL-path
<TR><TD>partial <TD> -- <TD>represent (MOUNTed) URLs as partial URLs if possible
<TR><TD>full    <TD> -- <TD>convert all of URLs to full URLs
</TABLE>
</UL>
<P>
The special <I>convList</I> URICONV="+" means loading the default URICONV
configuration (no <I>attrList</I> in this case in the current implementation).
The <I>attrList</I> is a list of attributes names each may be postfixed
with an element name.  A special attributes name "+" means the
default set of attributes.  An attribute prefixed with "-"
character is excluded from the calculated set of attributes.
<P>
Another special <I>convList</I> URICONV="where:any" enables searching URL
to be rewritten not only in HTML tags but also
in XML, JavaScript, CSS (Cascading Style Sheets) and SWF (Shockwave Flush).
<P>
Example:
<KBD>
<UL>
URICONV=mount,normal,partial:+  -- might be the default after Ver.6<BR>
URICONV=full:+,-HREF/BASE       -- rewrite everything except HREF/BASE<BR>
URICONV=dump                    -- show the current URICONV config.<BR>
URICONV=+ URICONV=mount:-SRC/IMG URICONV=full:SRC/IMG<BR>
</UL>
</KBD>
</UL>
</A>

<A NAME=BASEURL>
<PRE>
BASEURL parameter   ==  BASEURL=<I>URL</I>
                    --  default: none
</PRE>
<UL>
The base of (virtual) URL of this server which will be embedded
in each absolute URL generated by the DeleGate: ex. icon URLs
in HTML pages generated by NNTP/HTTP gateway DeleGate.
<P>
When an origin/gateway HTTP-DeleGate received "Host:<I>vhost1</I>" in
a request header, it overrides BASEURL="http://<I>vhost0</I>" parameter
to have "<I>vhost1</I>" be the base URL of the DeleGate.
To override the "Host:" header by BASEURL, prefix "-" to a host name as
BASEURL="http://-<I>vhost0</I>".
<P>
Example:
<UL>
<KBD>
MOUNT='/* nntp://newsserver/*" BASEURL="http://wwwserver/news"<BR>
</KBD>
// this will be useful when a HTTP server "http://wwwserver" is mapping<BR>
// its path "/news" to the root of this HTTP-DeleGate.
</UL>
</UL>
</A>

<A NAME=DELEGATE>
<PRE>
DELEGATE parameter  ==  DELEGATE=<I>gwHost:Port</I>[:<I>ProtoList</I>]
                    --  default: DELEGATE=<I>currentHost</I>:<I>currentPort</I>
</PRE>
<UL>
This parameter seems to be almost superseded by BASEURL, RELAY, and
URICONV parameters.
<P>
Originally, this parameter is introduced to control proxying mode for
non-CERN HTTP type proxy (including gopher proxy) by rewriting a <I>URL</I>
(or pointer) with <A HREF="#DGproxy"><I>gateway</I>-_-<I>URL</I></A>
or <I>proto</I>://<I>gwHost:Port</I>/-_-<I>URL</I> notation,
where the <I>gwHost:Port</I> part is generated and embedded by DeleGate.
<BR>
This parameter is introduced to customize the representation of
the <I>gwHost:Port</I> part.
It is a representation of the entrance port of this DeleGate
which must be resolvable and reachable from clients.
To make it be most usable, the default value of <I>gwHost</I> is
that of current network interface of the host of this DeleGate
through which the current client reached to this DeleGate,
and it is represented in raw IP address number so that clients can
reach the DeleGate even if they don't know how to resolve
the host name of the DeleGate.
<BR>
Exceptionally, if the entrance port is specified with
with an explicit network interface like "-P<I>host</I>:<I>port</I>,
the default value of DELEGATE is set to the <I>host</I>:<I>port</I>.
<BR>
By specifying an optional <I>ProtoList</I>,
you can limit to which protocols this proxying is applied.
URLs (or pointers) in a response message are rewritten
prefixed with "<I>proto</I>://<I>gwHost:Port</I>/-_-" so that
the request to it is directed again to this DeleGate
(at <I>gwHost</I>:<I>Port</I>), if the protocol is included in
the <I>ProtoList</I>.
<P>
Thus you can disable the proxying mode specifying non existing
entrance port and an empty <I>ProtoList</I> like DELEGATE="-:0:-all".
But this can be done more simply by RELAY parameter and it is
disabled by default in recent versions.
</UL>
</A>


<A NAME=COUNTER>
<PRE>
COUNTER parameter   ==  COUNTER=<I>listOfCounterControl</I>
    <I>counterControl</I>  ==  do | total | acc | ssi | ref | err | ro | no | mntpV
                    --  default: COUNTER=no
                    --  restriction: applicable to HTTP, SMTP, FTP and DNS
</PRE>
<UL>
Specify the usage of access counters.
<BR>(CAUTION: the current implementation of the counter in DeleGate/9.X
is tentative thus the location and the format of the counter file might be
modified and become incompatible in future)
<UL>
<DL>
    <DT><KBD>do</KBD> -- enable all counters including "total,acc,ssi,ref,err"
    <DT><KBD>total</KBD> -- enable the total hit counter of this server
    <DT><KBD>acc</KBD> -- enable access counters for each access to each URL
    <DT><KBD>ssi</KBD> -- enable access counters for SSI (by PAGE_COUNT in .shtml)
    <DT><KBD>ref</KBD> -- enable referrer counters for HTTP "Referer:"
    <DT><KBD>err</KBD> -- enable error counters (for SMTP)
    <DT><KBD>ro</KBD> -- enable counters in read-only
    <DT><KBD>no</KBD> -- disable counters [default]
    <DT><KBD>mntpV</KBD> -- use the counter of the MOUNT point (vURL) instead of each URL
</DL>
</UL>
If enabled with <KBD>COUNTER="do"</KBD>, all access counters for any
requests, referrers, and errors are incremented.
If enabled with <KBD>"total"</KBD>, the access counter for any requests
to this server is incremented.
If enabled with <KBD>"acc"</KBD>, access counters for any requests
to each target <I>URL</I> is incremented.
If enabled with <KBD>"ssi"</KBD>, only the access counter for the URL
of a SHTML page including a SSI <KBD>PAGE_COUNT</KBD> reference
is incremented when the page is accessed.
If enabled with <KBD>"ref"</KBD>, the referrer counter of the URL in the
HTTP "Referer:" fields is incremented.
<P>
Each access counter is stored in a file at
"<KBD>ADMDIR</KBD>/counts/access/<I>URL</I>#count".
Each counter file starts with a line consists of the numbers of accesses
in ASCII decimal format so that it can be initialized or modified manually.
The line can contain three numbers;
the first one is the total count,
the second one is the count excluding repetitive accesses from 
the same client,
and the third one is the count excluding repetitive access from
one of recent ten clients.
Each count are represented as <KBD>%T</KBD>, <KBD>%U</KBD>
and <KBD>%V</KBD> respectively in the format string described below.
<P>
The counter can be displayed in a specified format using
<A HREF=#SSI.shtml>SSI</A> as the <KBD>PAGE_COUNT</KBD>
or <KBD>COUNTER</KBD> value.
If no "url" attribute is specified in a tag, the URL of the SHTML file
containing the tag is implied.

Counter values are converted to a printable character string following
to the format string given in the "<KBD>fmt=</KBD>..." attribute.
The default format is "<KBD>%T</KBD>".
<P>
Format Specifiers:
<UL>
<DL>
    <DT><KBD>%T</KBD>  -- total count
    <DT><KBD>%U</KBD>  -- the count excluding repetitive accesses form a client
    <DT><KBD>%V</KBD>  -- the count excluding repetitive accesses from recent 10 clients
    <DT><KBD>%N</KBD>  -- the number of networks [ 0 - 1023 ]
    <DT><KBD>%M</KBD>  -- the map of networks
    <DT><KBD>%L</KBD>  -- the list of the last ten clients
    <DT><KBD>%mT %mU %mV</KBD> -- mean counts per day
    <DT><KBD>%mHT %mHU %mHV</KBD> -- mean counts per hour
    <DT><KBD>%tC</KBD> -- the time of the first count (counter creation)
    <DT><KBD>%tT %tU %tV</KBD> -- the time of update of each count
</DL>
</UL>
The specifier <KBD>%N</KBD> represents the number of networks of clients
where each network is with net-mask of 10 bits (0xFFC00000 255.192.0.0/10).
This means that the whole IPv4 address space is divided into 1024 networks.
So the <KBD>%N</KBD> represents the distribution of clients onto networks
over the address space as a coverage value in per-mill.
<KBD>%M</KBD> shows the distribution of clients as a visual map.
<P>
Example:
<KBD>
<UL>
<DL>
    <DT>&lt;!--#echo var=PAGE_COUNT --&gt;
    <DT>&lt;!--#echo var=COUNTER --&gt;
    <DT>&lt;!--#echo var=COUNTER fmt="%T hits since %tC" --&gt;
    <DT>&lt;!--#echo var=COUNTER url="<I>URL</I>" --&gt;
    <DT>&lt;!--#echo var=COUNTER fmt="%U/%T hits" --&gt;
    <DT>&lt;!--#echo var=COUNTER url="<I>URL</I>" fmt="%U/%T hits" --&gt;
</DL>
</UL>
</KBD>
<P>
The total count is displayed by <KBD>TOTAL_HITS</KBD> tag or by
<KBD>COUNTER</KBD> tag with "<KBD>sel=total</KBD>".
The referrer counter of a URL is incremented when the URL is in "Referer:"
header in a HTTP request.
Each referrer counter is stored in a file at
"<KBD>ADMDIR</KBD>/counts/referer/<I>URL</I>#count-ref".
The referrer counter can be displayed with "<KBD>sel=ref</KBD>"
attribute in the <KBD>COUNTER</KBD> tag.
<P>
Example:
<KBD>
<UL>
<DL>
    <DT>&lt;!--#echo var=TOTAL_HITS --&gt;
    <DT>&lt;!--#echo var=COUNTER sel=total --&gt;
    <DT>&lt;!--#echo var=COUNTER url="<I>URL</I>" fmt="%U/%T refs" sel=ref --&gt;
</DL>
</UL>
</KBD>
<P>
Enabling all counters for each URL can be expensive and/or unnecessary.
You can reduce counters by using the counter of a MOUNT point as the
representative, or using only total access counters of the server. 
In the following example, counters for all URLs is enabled by default
(with <KBD>COUNTER=do</KBD>),
while counters for URLs under <KBD>/srv1/</KBD> is represented by
the counter of <KBD>/srv1/</KBD>,
and only the server's total counter and SSI counters are enabled for
URLs under <KBD>/mine/</KBD>.
As shown in this example, <KBD>COUNTER</KBD> can be specified as a
MountOption of which initial value is inherited from the
<KBD>COUNTER</KBD> parameter.
<P>
Example:
<PRE>
<KBD>
    COUNTER=do
    MOUNT="/srv1/* http://srv1/*  COUNTER=mntpV"
    MOUNT="/mine/* file:dirpath/* COUNTER=no,total,ssi"
</KBD>
</PRE>
</UL>
</A>


<A NAME=CACHE>
<PRE>
CACHE parameter*    ==  CACHE=<I>cacheControl</I>[,<I>cacheControl</I>]*[:<I>connMap</I>]
      <I>cacheControl</I>  ==  do | no | ro
           <I>connMap</I>  ==  <I>ProtoList</I>[:[<I>dstHostList</I>][:<I>srcHostList</I>]]
                    --  default: none
                    --  restriction: applicable to HTTP, FTP, NNTP and Gopher
</PRE>
<UL>
Specify a restriction of cache usage.
<UL>
<DL>
    <DT><KBD>do</KBD> -- create <A HREF="#CACHEDIR">CACHEDIR</A> if not exist (to enable cache)
    <DT><KBD>no</KBD> -- disable cache
    <DT><KBD>ro</KBD> -- use cache in read-only
</DL>
</UL>
Cache is enabled by default.
Cache will be disabled if the CACHEDIR directory does not exist,
or it is not readable and writable by the DeleGate,
or CACHE="no" is specified,
or "cache" is not included in CONNECT.
</UL>
</A>


<A NAME=EXPIRE>
<PRE>
EXPIRE parameter*   ==  EXPIRE=<I>validity</I>[/<I>custody</I>][:<I>connMap</I>]
           <I>connMap</I>  ==  <I>ProtoList</I>:<I>dstHostList</I>:<I>srcHostList</I>
          <I>validity</I>  ==  <I>period</I>
           <I>custody</I>  ==  <I>period</I>
            <I>period</I>  ==  <I>Num</I>[d|h|m|s]
                    --  default: EXPIRE=1h
</PRE>
<UL>
EXPIRE specifies the term of validity of cached data, in unit of
days, hours, minutes, or seconds.  Validity does not mean active removal of
cached data by DeleGate; DeleGate merely ignores cached data if it
is older than the specified term.
</UL>
</A>

<A NAME=CACHEFILE>
<PRE>
CACHEFILE parameter ==  CACHEFILE=<I>fileNameSpec</I>
                    --  default: CACHEFILE='$[server:%P/%L/%p]'
</PRE>
<UL>
CACHEFILE specifies how the file name of a cache file is formed.
The name is derived mainly from informations about server host and
requested URL.
Those informations are specified in the format "$[server:<I>format</I>]"
where the <I>format</I> is a sequence of symbols each refers a part of an URL
<I>scheme</I>://<I>host</I>.<I>d2</I>.<I>d1</I>:<I>port</I>/<I>path</I>
as follows:
<P>
<UL>
<TABLE BORDER=0 CELLSPACING=0>
<TR><TD><KBD>%P</KBD><TD> -- <TD><I>scheme</I>
    <TD>Protocol name part       
<TR><TD><KBD>%L</KBD><TD>--<TD><I>host</I>.<I>d2</I>.<I>d1</I>:<I>port</I>
    <TD>Login (or site) part               
<TR><TD><KBD>%H</KBD><TD>--<TD><I>host</I>.<I>d2</I>.<I>d1</I>
    <TD>Host name                
<TR><TD><KBD>%T</KBD><TD>--<TD><I>port</I>
    <TD>Port number              
<TR><TD><KBD>%h</KBD><TD>--<TD><I>d1</I>/<I>d2</I>/<I>host</I>
    <TD>hierarchical host name directory      
<TR><TD><KBD>%d</KBD><TD>--<TD><I>d1</I>/<I>d2</I>
    <TD>hierarchical domain name directory    
<TR><TD><KBD>%1</KBD><TD>--<TD><I>d1</I>
    <TD>top level domain         
<TR><TD><KBD>%2</KBD><TD>--<TD><I>d2</I>
    <TD>second level domain      
<TR><TD><KBD>%p</KBD><TD>--<TD><I>path</I>
    <TD>URL-path part            
<TR><TD><KBD>%Q</KBD><TD>--<TD><I>host</I>.<I>d2</I>.<I>d1</I>.<I>d0</I>
    <TD>use FQDN of a host name (like %Q%L or %Q%H)
</TABLE>
</UL>

<P>
Another formatting pattern is "$[hash:<I>format</I>]" which
hashes a string generated by <I>format</I> into
hexadecimal value ranging from <KBD>"00"</KBD> to <KBD>"1f"</KBD>.
This will be useful to divide a single huge directory containing all
servers into 32 small directories, which can be on physically
different disks.
<BR>
Example:
<UL>
<KBD>
CACHEFILE='$[server:%P]/$[hash:%H]/$[server:%L/%p]'
</KBD>
</UL>
</UL>
</A>


<A NAME=ICP>
<PRE>
ICP parameter*      ==  ICP=<I>icpServerList</I>[:<I>icpServerSpec</I>[:<I>connMap</I>]]
     <I>icpServerList</I>  ==  <I>icpServer</I>[,<I>icpServer</I>]*
         <I>icpServer</I>  ==  <I>icpHost</I>[/<I>icpType</I>/<I>proxyPort</I>/<I>icpPort</I>]
     <I>icpServerSpec</I>  ==  <I>icpOptions</I>:<I>proxyPort</I>:<I>icpPort</I>
           <I>connMap</I>  ==  <I>ProtoList</I>:<I>dstHostList</I>:<I>srcHostList</I>
                    --  default: none
                    --  restriction: applicable to {HTTP,FTP}-DeleGate
</PRE>
<UL>
If specified, and if "icp" is included in the CONNECT sequence,
a HTTP-DeleGate will try to get a requested resource
from specified ICP server.
The meaning and default value of each field is as follows:
<P>
<DL>
<DT><I>icpHost</I>:
<DD>The host name or IP address of the ICP server [localhost]
<DT><I>icpType</I>:
<DD>
<TABLE BORDER=0 CELLSPACING=0>
<TR><TD><KBD>s</KBD><TD> -- the ICP server is a "sibling" [default]
<TR><TD><KBD>p</KBD><TD> -- the ICP server is a "parent"
<TR><TD><KBD>l</KBD><TD> -- the ICP server is a "listener" which never respond
<TR><TD><KBD>n</KBD><TD> -- the ICP server is a navigation proxy
<TR><TD><KBD>o</KBD><TD> -- require HIT_OBJ response
<TR><TD><KBD>H</KBD><TD> -- the object server is a HTTP proxy [default]
<TR><TD><KBD>D</KBD><TD> -- the object server is a MASTER-DeleGate.
<TR><TD><KBD>O</KBD><TD> -- the object server is an origin server.
</TABLE>
<DT><I>proxyPort</I>:
<DD>The port number of the corresponding object server [8080].
<DT><I>icpPort</I>:
<DD>The port number of ICP protocol [3130].
<DT><I>icpOptions</I>:
<DD>
<TABLE BORDER=0 CELLSPACING=0>
<TR><TD>timeout/<I>N</I><TD> -- period to wait response as an ICP client (in seconds)[2.0]
<TR><TD><KBD>parent</KBD><TD> -- mark the default type of <I>icpServers</I> as "parent"
<TR><TD><KBD>listener</KBD><TD> -- mark the default type of <I>icpServers</I> as "listener"
<TR><TD><KBD>hitobj</KBD><TD> -- enable HIT_OBJ for all <I>icpServers</I> by default
<TR><TD><KBD>Origin</KBD><TD> -- object servers are origin server
<TR><TD><KBD>DeleGate</KBD><TD> -- object servers are DeleGate
</TABLE>
</DL>
<P>
Example:
<UL>
<KBD>
ICP=icphost<BR>
</KBD>
// This is the simplest usage which is the abbreviation of <BR>
// ICP="icphost/sH/8080/3130:timeout/2.0:8080:3130:*:*:*"  <BR>
<P>
<KBD>
ICP="host0"<BR>
ICP="host0//8080/3130"<BR>
ICP="host0::8080:3130"<BR>
ICP="host1:timeout/1.0:::http,ftp:!*.my.domain:*.my.domain"<BR>
ICP="host1,host2/O/80/13130:timeout/2.0:8080:3130"<BR>
</KBD>
</UL>
</UL>
</A>

<A NAME=CHARCODE>
<PRE>
CHARCODE parameter* ==  CHARCODE=[<I>inputCode</I>/]<I>outputCode</I>[:[tosv][:connMap]]
        <I>outputCode</I>  ==  <I>charCode</I>
          <I>charCode</I>  ==  iso-2022-jp | euc-jp | shift_jis | utf-8 | us-ascii |
                               JIS | EUC | SJIS | UTF8 | ASCII | guess
           <I>connMap</I>  ==  [<I>ProtoList</I>][:[<I>dstHostList</I>][:[<I>srcHostList</I>]]]
                    --  restriction: applicable to HTTP, FTP, SMTP, POP,
                                     NNTP, Telnet, Tcprelay
                    --  default: none
</PRE>
<UL>
If specified, DeleGate will convert the JIS code in text type response
message into the specified character code.
When UTF8 is specified, a mapping table necessary for conversion between
Unicode and JIS code is downloaded automatically from the server
at Unicode.Org via DeleGate.ORG.
<!--
The full specification format of the parameter value is
<I>inputCode</I>/<I>outputCode</I>.  CHARCODE=JIS is the abbreviation of
CHARCODE=JP/JIS where JP means Japanese text encoding {JIS,EUC,SJIS,UTF8}.
-->
<P>
The pseudo code name "guess" means not doing conversion but supplement
the "charset" attribute in "Content-Type" header in a message
when it is lacking, guessing it from the body of the message.
This is useful when a viewer program (ex. a web browser)
of the message is not localized to Japanese thus non-ASCII codes like
EUC-JP are guessed as European or so by the viewer.
<P>
If "<KBD>tosv</KBD>" is specified, the conversion is applied to
the request message (or a message toward a server).
The conversion is also applied to fragments of Japanese text in a HTTP request
message encoded in "%XX" in its request URL or in the body of a POST
message (when it is encoded in Content-Type: application/x-www-form-urlencoded).
The set of values of Content-Type to which the conversion is applied can be
specified with HTTPCONF=<A HREF=#post-ccx-type>post-ccx-type</A>.
<P>
The application of the conversion can be limited only to a specified
set of protocols, servers and clients specified with <I>connMap</I>.
In the <I>connMap</I>, the default value of <I>ProtoList</I>,
<I>dstHostList</I> and <I>srcHostList</I> is "*" which matches
any protocols or hosts.
<P>
Example: send response in UTF8 to clients and send request
in Shift_JIS to HTTP servers<UL><KBD>
CHARCODE=UTF8 CHARCODE=SJIS:tosv:http<BR>
</KBD></UL>
<P>
For the FTP protocol, the conversion is applied only to the data
of the ASCII type relayed on the data-connections by default.
It is applied also to binary data or data on the control-connection
with FTPCONF="ccx:any".
<P>
To enable this parameter for internet-mail/news protocols
(SMTP, POP and NNTP),
also <A HREF="#MIMECONV">MIMECONV</A> parameter must be specified
so that it enables character conversion (enabled by default).
<P>
A HTTP client can override this specification by sending its choice
in "Accept-Language" field in a request message,
which may be configurable in each client (WWW browser).
For example, if
"Accept-Language: (charcode=EUC)" is sent in a request from client,
the response text will be converted into EUC regardless of CHARCODE
specification of the DeleGate.  If
"Accept-Language: (charcode=THRU)" is specified,
any conversion specified by the administrator of this DeleGate is disabled.
</UL>
</A>

<A NAME=CHARMAP>
<PRE>
CHARMAP parameter*  ==  CHARMAP=<I>mapType</I>:<I>charMap</I>[,<I>charMap</I>]*[:tosv]
           <I>mapType</I>  ==  ascii | ucs | jis | ucsjis | jisucs
           <I>charMap</I>  ==  <I>inCharCode1</I>[-<I>inCharCode2</I>]/<I>outCharCode2</I>[-[<I>outCharCode2</I>]]
          <I>charCode</I>  ==  hexa-decimal code | single ASCII character
                    --  default: none
</PRE>
<UL>
If specified, a character in texts relayed in a message of an application
protocol is mapped to another character.
By default, the mapping is applied to the response data to client.
It can be applied to the request data to server specifying "<KBD>:tosv</KBD>".
<P>
A character to be mapped is represented in a hexa-decimal value of it
(represented in more than 2 columns), or a direct character in a single columns.
The characters in the JIS X 0208 character set encoded in the variants of its
encoding (ISO-2022-JP, EUC-JP, and Shift_JIS) are represented in
its JIS code value without the most significant bits (8080) as "2121".
The characters in the JIS X 0212 character set are represented in its
JIS code value prefixed with "1" as "1222F".
<BR>
If <I>inCharCode2</I> and <I>outCharCode2</I> is specified, each character in
the range is mapped to the corresponding character.
If no -<I>outCharCode2</I> is given, any input characters in the range
is mapped to <I>outCharCode1</I>.
<P>
The <I>mapType</I> is one of followings:
<UL>
<DL>
<DT><KBD>ascii </KBD> -- ASCII to ASCII mapping
<DT><KBD>ucs   </KBD> -- UCS to UCS mapping when the input is coded in UTF-8
<DT><KBD>jis   </KBD> -- JIS to JIS mapping when the character set of input is JIS X 0208
<DT><KBD>ucsjis</KBD> -- UCS to JIS mapping in the conversion by CHARCODE=JIS or SJIS or EUC
<DT><KBD>jisucs</KBD> -- JIS to UCS mapping in the conversion by CHARCODE=UTF8
</DL>
</UL>
<P>
Example: reverse lowercase and upper case
<UL><KBD>CHARMAP=ascii:a-z/A-Z,A-Z/a-z<BR></KBD></UL>

<P>
Example: "rot13" encoding
<UL><KBD>CHARMAP=ascii:a-m/n-z,n-z/a-m,A-M/N-Z,N-Z/A-M<BR></KBD></UL>

<P>
Example: replace any Japanese character in JIS X 0208 with "GETA MARK"
<UL><KBD>CHARMAP=jis:0100-7F7F/222E<BR></KBD></UL>

<P>
Example: replace any Japanese character in JIS X 0212 with "GETA MARK"
<UL><KBD>CHARMAP=jis:10000-1FFFF/222E<BR></KBD></UL>

<P>
Example: represents unknown characters by "WHITE SQUARE" instead of "GETA MARK"
<UL><KBD>CHARMAP=jis:0000/2222<BR></KBD></UL>
</UL>
</A>


<A NAME=HTMLCONV>
<PRE>
HTMLCONV parameter  ==  HTMLCONV=<I>convList</I>
          <I>convList</I>  ==  <I>conv</I>[,<I>conv</I>]*
              <I>conv</I>  ==  deent | enent | fullurl
                    --  default: HTMLCONV=deent
</PRE>
<UL>
Specify a list of flags to control conversion for HTML text in
a HTTP response message.
<P>

<UL>
<TABLE BORDER=0 CELLSPACING=0>
<TR><TD>deent   <TD> -- <TD> decode entity symbol
<TR><TD>enent   <TD> -- <TD> encode entity symbol
<TR><TD>fullurl <TD> -- <TD id=wrap> convert all of URLs to full URLs
             (equals to URICONV="full:+,-HREF/BASE")
</TABLE>
</UL>
<P>
"deent" and "enent" control encoding and decoding of special
characters between HTML and plain text
("&amp;lt;" to/from "&lt;" for example)
when such characters appear in a text of
multi-byte charset (like ISO-2022-JP).
If "deent" is specified, encoded entity symbol appearing
in multi-byte charset text will be decoded.
This may be useful to recover a text
including characters indiscriminately encoded by
encoder which does not care multi-byte characters.
<BR>
If "enent" is specified then entity symbols appearing
out of multi-byte charset text will be encoded.
This may be useful in case of NNTP-DeleGate to be accessed by
WWW client.
If empty list is specified, any conversion is disabled.
</UL>
</A>


<A NAME=MIMECONV>
<PRE>
MIMECONV parameter  ==  MIMECONV=<I>mimeConv</I>[,<I>mimeConv</I>]
          <I>mimeConv</I>  ==  thru | charcode | nospenc
                                    | textonly | alt:first | alt:plain
                    --  default: none
                    --  MIMECONV="" if CHARCODE parameter is given
</PRE>
<UL>
Control MIME encoding/decoding in NNTP/POP/SMTP DeleGate.
MIMECONV=thru disables any MIME encoding/decoding, and
MIMECONV=charcode enables only character code conversion.
MIMECONV=nospenc disables a special encoding of space character in
non-ASCII (ISO-2022-JP) text in MIME header.
<P>
Here is a group of options for filtering a "multipart/*" message
to convert it into a plain message by selecting or unfolding the
list of parts as follows:
<DL><DT><DD>
<DL>
<DT><KBD>textonly</KBD> -- only the first text/* part in multipart/*
<DT><KBD>alt:first</KBD> -- only the first alternative in multipart/alternative
<DT><KBD>alt:unfold</KBD> -- all of alternatives in multipart/alternative
</DL>
</DD></DT></DL>
</UL>
</A>


<A NAME=FCL>
<A NAME=FTOCL>
<A NAME=FFROMCL>
<A NAME=FMD>
<A NAME=FTOMD>
<A NAME=FFROMMD>
<A NAME=FSV>
<A NAME=FTOSV>
<A NAME=FFROMSV>
<A NAME=filter-params>
<PRE>
FCL parameter       ==  FCL=<I>filterCommand</I>
FTOCL parameter     ==  FTOCL=<I>filterCommand</I>
FFROMCL parameter   ==  FFROMCL=<I>filterCommand</I>
FSV parameter       ==  FSV=<I>filterCommand</I>
FTOSV parameter     ==  FTOSV=<I>filterCommand</I>
FFROMSV parameter   ==  FFROMSV=<I>filterCommand</I>
FMD parameter       ==  FMD=<I>filterCommand</I>
FTOMD parameter     ==  FTOMD=<I>filterCommand</I>
FFROMMD parameter   ==  FFROMMD=<I>filterCommand</I>
<I>filterCommand</I>       ==  [-s,][-p,][-w,]<I>command</I>
                    --  default: none
</PRE>
<UL>
Specify a <A HREF=#CFIscript>filter</A> command
to be applied to data transmitted between DeleGate and clients,
or between DeleGate and servers.
When a <I>filterCommand</I> is specified in relative path name,
it is searched in <A HREF="#LIBPATH">LIBPATH</A>.
<P>
Filters can be applied conditionally using
<A HREF="#cond-filter">CMAP</A>
based on circuit level information, or
using <A HREF="#CFIscript">CFI script</A>
based on application level information.
<P>
<A NAME=cfistat TITLE="Filter Control Options"><P>
FILTER CONTROL OPTIONS: options to get status information from,
or control synchronization with filter program.
<DL>
<DT>
<DD>
 <KBD>-s</KBD> -- get status information (ex. authentication) from filter<BR>
 <KBD>-w</KBD> -- wait the filter process to exit before starting relay<BR>
 <KBD>-p</KBD> -- detach the filter when it exits then continue relaying<BR>
</DD>
</DL>
</A>
<P>
<A NAME=tee TITLE="tee filter"><P>
BUILT-IN FILTERS: if a <I>filterCommand</I> is prefixed with "-",
then it is a filter built-in to DeleGate.
<UL>
<DL>
<DT>credhyFilter == -credhy
... encryption/decryption filter
<DD>
<DT>teeFilter  ==  -tee[<I>teeOpt</I>]*[SPACE <I>filePath</I>]
... filter like tee(1) command
<DT>catFilter  ==  -cat[<I>teeOpt</I>]
... filter like cat(1) command
<DT><I>teeOpt</I>  ==  -h | -n | -t | -v | -l | -e
<DD>
<KBD>-h</KBD> -- output header part only<BR>
<KBD>-n</KBD> -- number the output lines<BR>
<KBD>-t</KBD> -- time stamp for each output line<BR>
<KBD>-v</KBD> -- visualize invisible characters<BR>
<KBD>-l</KBD> -- (with -tee) output to LOGFILE instead of stderr (default)<BR>
<KBD>-e</KBD> -- (with -tee) output to stderr<BR>
<DT>codeconvFilter  ==  -<I>charCode</I>
... char code conversion as <A HREF="#CHARCODE">CHARCODE</A>
<DT><I>charCode</I>  ==  jis | sjis | euc | utf8
</DL>
</UL>
Example:<UL>
<KBD>
FTOCL=-tee-h-n FTOSV=-tee
</KBD>
</UL>
</A>
</UL>
</UL>
</A>
</A>
</A>
</A>
</A>
</A>
</A>
</A>
</A>
</A>


<A NAME=XCOM>
<A NAME=XFIL>
<PRE>
XCOM parameter      ==  XCOM=<I>filterCommand</I>
XFIL parameter      ==  XFIL=<I>filterCommand</I>
                    --  default: none
</PRE>
<UL>
XCOM and XFIL is used together with SERVER="exec" parameter.
A special protocol name "exec" means executing some local command
rather than connecting to a server. With "exec", DeleGate will work
like simple <I>inetd</I> or <I>wrapper</I>.
What will be executed is specified with either XCOM or XFIL parameter.
Commands executed as XCOM will be given standard I/O
which are bound for a socket connected to the client.
Commands executed as XFIL will be given standard I/O
which are redirected to a pair of pipes bound for DeleGate,
which relays it to and from the client.
<P>
On WindowsNT and OS/2, commands executed as XCOM will be given a
environment variable "SOCKHANDLE_CLIENT"
which have the handle value of the inherited socket
connected to the client.
</UL>
</A>
</A>


<A NAME=CHROOT>
<PRE>
CHROOT parameter    ==  CHROOT=<I>dirPath</I>
                    --  default:  none
                    --  restriction: super-user only on most of Unix
</PRE>
<UL>
Change the root of file system to <I>dirPath</I> at the start
using chroot(2) system call,
restricting accessible (visible) files to ones under <I>dirPath</I>.
This is effective to isolate the DeleGate from the whole file system
of the host machine preventing DeleGate from possible destruction of them
by its bug or by intrusion.
<A HREF=#DGROOT>DGROOT</A> is interpreted after the root is changed. 
<BR>
A special case CHROOT="/" means using the value of
(default or specified) DGROOT as CHROOT and set DGROOT="/".
That is, DGROOT="/<I>path</I>" with CHROOT="/" are equal to
DGROOT="/" with CHROOT="/<I>path</I>".
</UL>
</A>

<A NAME=DGROOT>
<PRE>
DGROOT parameter    ==  DGROOT=<I>dirPath</I>
                    --  default: if ${STARTDIR}/DGROOT exists then use it, or
                                  on Unix: '/' if <A HREF=#CHROOT>CHROOT</A> is set or
                                           '${HOME}/delegate' or
                                           '/var/spool/delegate-${OWNER}' or
                                           '/tmp/delegate-${OWNER}'
                               on Windows: '/Program Files/DeleGate'
</PRE>
<UL>
All of sub-directories (LOGDIR, ADMDIR, CACHEDIR, WORKDIR, ETCDIR,
ACTDIR and TMPDIR) will be located under the DGROOT by default.
<BR>
At the start up time (on Unix), DeleGate searches an available DGROOT
which is both readable and writable by the OWNER.
When a candidate directory does not exist, DeleGate tries to make the
directory by itself.
If DGROOT is specified explicitly, it is tried first.
If it failed or no DGROOT is given,
default candidates will be tried in order until an available directory
is found.
</UL>
</A>


<A NAME=SHARE>
<PRE>
SHARE parameter     ==  SHARE=<I>dirPatternList</I>
                    --  default: empty
</PRE>
<UL>
If specified, created directories or files
which has name matches with given pattern
will be set with mode
0777(rwxrwxrwx) or 0666(rw-rw-rw-) respectively,
to be sharable among arbitrary users.
When a pattern is specified in non-absolute form, it is regarded as
relative to DGROOT.
By default, directories or files will be created with
mode 0755(rwxr-xr-x) or 0666(rw-rw-rw-),
as modified by UMASK which is 022 typically.
<P>
Example:
<UL>
// make everything sharable<BR>
<KBD>SHARE=""</KBD><BR>
// share cache and log under DGROOT<BR>
<KBD>SHARE="cache/*,log/*"</KBD><BR>
// share directories with older versions<BR>
<KBD>SHARE='${CACHEDIR}/*' CACHEDIR='/var/spool/delegate-anybody'</KBD><BR>
<KBD>SHARE='${VARDIR}/*' VARDIR='/var/spool/delegate'</KBD><BR>
</UL>
</UL>
</A>

<A NAME=UMASK>
<PRE>
UMASK parameter     ==  UMASK=<I>mask</I>
                    --  default: <I>the value of umask(2)</I>
</PRE>
<UL>
Set <I>mask</I> for file creation mode, using umask(2) system call.
</UL>
</A>

<A NAME=VARDIR>
<PRE>
VARDIR parameter    ==  VARDIR=<I>dirPath</I>
                    --  default: VARDIR='${DGROOT?&amp;:/var/spool/delegate}'
</PRE>
<UL>
This parameter seems be obsolete after DGROOT has become standard in
DeleGate/6.0.
It specifies the default base of sub directories like DGROOT
except for ACTDIR and TMPDIR.
The default value of VARDIR is the value of DGROOT.
</UL>
</A>

<A NAME=CACHEDIR>
<PRE>
CACHEDIR parameter  ==  CACHEDIR=<I>dirPath</I>
                    --  default: CACHEDIR='${VARDIR}/cache'
</PRE>
<UL>
To enable cache, the directory CACHEDIR must exist and
is both readable and writable by the DeleGate.
It will be automatically created with CACHE="do"
with necessary permissions.
</UL>
</A>

<A NAME=ETCDIR>
<PRE>
ETCDIR parameter    ==  ETCDIR=<I>dirPath</I>
                    --  default: ETCDIR='${VARDIR}/etc'
</PRE>
<UL>
The directory to hold persistent files for configuration and
administration of DeleGate.
Configuration files for origin SMTP-DeleGate(<A HREF="#SMTPGATE">SMTPGATE</A>)
and origin NNTP-DeleGate (<A HREF="#origin_NNTP">NNTP</A>) are placed hear.
</UL>
</A>

<A NAME=ADMDIR>
<PRE>
ADMDIR parameter    ==  ADMDIR=<I>dirPath</I>
                    --  default: ADMDIR='${VARDIR}/adm'
</PRE>
<UL>
The directory to hold genarated files for administration of DeleGate,
including files for <A HREF="#defense">shutout</A> defense,
password repository of <A HREF=#func_auth>-Fauth</A>,
identification code of executalbe file of DeleGate,
server's statistics file,
and COUNTER.
</UL>
</A>


<A NAME=LOGDIR>
<PRE>
LOGDIR parameter    ==  LOGDIR=<I>dirPath</I>
                    --  default: LOGDIR='${VARDIR}/log'
</PRE>
<UL>
The default directory where log files are placed.
</UL>
</A>

<A NAME=LOGFILE>
<A NAME=PROTOLOG>
<A NAME=ERRORLOG>
<A NAME=TRACELOG>
<PRE>
LOGFILE parameter   ==  LOGFILE=[<I>LogFilename</I>]
PROTOLOG parameter  ==  PROTOLOG=[<I>LogFilename</I>][:<I>logFormat</I>]
ERRORLOG parameter  ==  ERRORLOG=<I>LogFilename</I>
TRACELOG parameter  ==  TRACELOG=<I>LogFilename</I>
                    --  default: LOGFILE='${LOGDIR}/${PORT}'
                    --  default: PROTOLOG='${LOGDIR}/${PORT}.${PROTO}'
                    --  default: ERRORLOG='${LOGDIR}/errors.log'
                    --  default: TRACELOG='${LOGDIR}/ptrace.log'
</PRE>
<UL>
If <I>LogFilename</I>s are specified in a relative path then they are placed
under ${LOGDIR}.  If those names start with "./" then they are placed
under ${WORKDIR}.
<P>
The patterns ${PROTO} and ${PORT} will be substituted with the
protocol name and the port number of this DeleGate respectively.
These files and directories will be created automatically by
DeleGate if possible.  You can stop logging by specifying null
file name like LOGFILE="" or PROTOLOG="".
<P>
The format of PROTOLOG for HTTP is compatible with
the <A HREF="#httplog"><I>common logfile format</I></A> and is customizable.
The format of PROTOLOG for FTP is compatible with
<A HREF="#xferlog"><I>xferlog</I></A>.
</UL>
</A>
</A>
</A>
</A>

<A NAME=SYSLOG>
<PRE>
SYSLOG parameter*   ==  SYSLOG=[<I>syslogOpts</I>,][<I>syslogServ</I>]
        <I>syslogOpts</I>  ==  <I>syslogOpt</I>[,<I>syslogOpts</I>]
         <I>syslogOpt</I>  ==  -vt | -vs | -vS | -vH | -f<I>name</I>
                    --  default: none
</PRE>
<UL>
This parameter specifies recording log data via the "syslog" service (RFC3164).
The "facility.priority" pair of logged data of <A HREF=#LOGFILE>LOGFILE</A>
is "daemon.debug" for usual data and "daemon.err" for errors.
(It will be divided into more detailed levels in the future.)
The log data of <A HREF=#PROTOLOG>PROTOLOG</A> is sent with "daemon.notice".
The facility name can be changed with a "-f<I>name</I>" option.
<P>
Multiple <KBD>SYSLOG</KBD> parameters can be specified to send a log data
to multiple different destinations each specified by a <I>syslogServ</I>.
A <I>syslogServ</I> is a URL of a syslog server or a local file.
The default <I>syslogServ</I> is the local logger to which log is sent
via the standard "syslog()" function.
For each destination, the log format or detailness can be specified by
prefixing a list of <I>syslogOpt</I> as follows:
<P>
<UL>
<TABLE BORDER=0 CELLSPACING=0>
<TR><TD><KBD>-vt</KBD></TD><TD> -- terse LOGFILE</TD></TR>
<TR><TD><KBD>-vs</KBD></TD><TD> -- without LOGFILE</TD></TR>
<TR><TD><KBD>-vS</KBD></TD><TD> -- without PROTOLOG</TD></TR>
<TR><TD><KBD>-vH</KBD></TD><TD> -- without the syslog header</TD></TR>
<TR><TD><KBD>-f<I>name</I>&nbsp;</KBD></TD><TD> -- use the facility <I>name</I> instead of "daemon"</TD></TR>
</TABLE>
</UL>
<P>
Example:
<UL>
<TABLE BORDER=0 CELLSPACING=0>
<TR><TD><KBD>SYSLOG=</KBD></TD><TD> -- to the local syslog</TD></TR>
<TR><TD><KBD>SYSLOG=syslog://<I>host</I></KBD></TD><TD> -- to a remote syslog server</TD></TR>
<TR><TD><KBD>SYSLOG=syslog://<I>host</I>:<I>port</I></KBD>&nbsp;</TD><TD> -- on a non-standard port</TD></TR>
<TR><TD><KBD>SYSLOG=/dev/tty</KBD></TD><TD> -- to the console</TD></TR>
<TR><TD><KBD>SYSLOG=file:<I>path</I></KBD></TD><TD> -- to a local file</TD></TR>
<TR><TD><KBD>SYSLOG=-vH,file:<I>path</I></KBD></TD><TD> -- without the syslog header</TD></TR>
<TR><TD><KBD>SYSLOG=-fdaemon</KBD></TD><TD> -- as the "daemon" facility (default)</TD></TR>
<TR><TD><KBD>SYSLOG=-flocal1</KBD></TD><TD> -- as the "local1" facility</TD></TR>
</TABLE>
</UL>
<P>
The source port (and the address) of syslog UDP packets to a remote
syslog server can be specified as
<KBD><A HREF=#SRCIF>SRCIF</A>=":8514:syslog"</KBD>
(or <KBD><A HREF=#SRCIF>SRCIF</A>="xx.xx.xx.xx:8514:syslog"</KBD>)
for example.<BR>
Switching syslog servers based on each client and server of the
application protocol is not (yet) supported.
</UL>
</A>

<A NAME=aging TITLE="LogFilename and Aging">
<P>
LogFilename and dirPath Substitution for Aging<BR>
<UL>
If the pattern "[date+<I>format</I>]" is included in the file name,
the <I>format</I> string is evaluated by strftime(3) compatible function
with the current time,
and will be substituted with the evaluated value.
This means that a log directory (or file) specified
will be divided into a granularity of specified time period,
thus it is <I>aged</I>.
Formats to represent typical time periods are as follows:
<P>
<UL>
<KBD>%Y</KBD> -- year (like 2000)<BR>
<KBD>%y</KBD> -- year without century [00-99]<BR>
<KBD>%m</KBD> -- month number [01-12]<BR>
<KBD>%d</KBD> -- day of month [01-31]<BR>
<KBD>%W</KBD> -- week number of year [00-53]<BR>
<KBD>%w</KBD> -- weekday number [0-6, Sunday=0]<BR>
<KBD>%H</KBD> -- hour [00-23]<BR>
</UL>
</P>

<P>
Example: aging a log file day by day and rotate by a month
<UL>
<KBD>
LOGFILE='${PORT}[date+.%d]'
</KBD>
</UL>
</P>

<P>
Example: make log directory hierarchical by date
<UL>
<KBD>
LOGDIR='log[date+/aged/%y/%m/%d]'
</KBD>
</UL>
</P>

<P>
The latest LOGFILE will be pointed with another file name
(hard link to it) which name is made by omitting
"[date+<I>format</I>]" parts from LOGFILE specification.
For example, by the LOGFILE specification in the above example,
logfile will be named like "log/aged/00/12/31/80.http"
while the latest one is given another name "log/80.http".
<P>
Another pattern for aging is "[start+<I>format</I>]"
which will be evaluated in the same way with
"date+" except that it will be substituted by
the time when the DeleGate started
(or restarted by SIGHUP or specified TIMEOUT=restart).
</UL>
</A>

<A NAME=EXPIRELOG>
<PRE>
EXPIRELOG parameter ==  EXPIRELOG=<I>LogFilename</I>
                    --  default: EXPIRELOG='${LOGDIR}/expire.log'
</PRE>
<UL>
The log-file for expiration by "-Fexpire" function or "-expire" action in CRON.
</UL>
</A>

<A NAME=WORKDIR>
<A NAME=ACTDIR>
<A NAME=TMPDIR>
<A NAME=PIDFILE>
<PRE>
WORKDIR parameter   ==  WORKDIR=<I>dirPath</I>
                    --  default: WORKDIR='${VARDIR}/work/${PORT}'
</PRE>
<UL>
If WORKDIR is not accessible, or if WORKDIR is not explicitly
specified when -vv option is given, then current directory (of
invoker of this DeleGate) will be used as WORKDIR.
</UL>

<PRE>
ACTDIR parameter    ==  ACTDIR=<I>dirPath</I>
TMPDIR parameter    ==  TMPDIR=<I>dirPath</I>
PIDFILE parameter   ==  PIDFILE=<I>fileName</I>
                    --  default: ACTDIR='${DGROOT}/act'
                    --  default: TMPDIR=<I>system dependent</I>
                    --  default: PIDFILE='${ACTDIR}/pid/${PORT}'
</PRE>
<UL>
Information about currently active servers are placed at ACTDIR.
Those are temporary files which are made on invocation of a
DeleGate server and are removed at its termination.
</UL>
</A>
</A>
</A>
</A>


<A NAME=HOSTS>
<PRE>
HOSTS parameter*    ==  HOSTS=<I>nameList</I>[/<I>addrList</I>]
          <I>nameList</I>  ==  <I>name</I> | {<I>name</I>[,<I>name</I>]*}
          <I>addrList</I>  ==  <I>addr</I> | {<I>addr</I>[,<I>addr</I>]*}
                    --  default: HOSTS=localhost/127.0.0.1
</PRE>
<UL>
List of domain-names/IP-addresses pairs which will override DNS
(or NIS or /etc/hosts table) data.
This could be used for speed-up of resolution for
frequently referred hosts, aliasing,
or relief of unknown hosts by any resolvers.
Multiple names or addresses could be specified in the
form {name1,name2,...}/{addr1,addr2,...}.
If only {name1,name2,...} is given without <I>addr</I> part,
it makes name1,name2,... be regarded as a single host.
</UL>
</A>

<A NAME=RESOLV>
<PRE>
RESOLV parameter    ==  RESOLV=[<I>resolver</I>[,<I>resolver</I>]*]
          <I>resolver</I>  ==  <I>resType</I>[:[<I>resParam</I>][:[<I>queryHostList</I>][:<I>clientHostList</I>]]]
           <I>resType</I>  ==  cache | file | nis | dns | sys
                    --  default: RESOLV=cache,file,nis,dns,sys
</PRE>
<UL>
Specify which name resolver should be used in what order.
<P>
<UL>
<TABLE BORDER=0 CELLSPACING=0>
<TR><TD>cache<TD> -- means cached result from following resolvers
<TR><TD>file <TD> -- means local hosts(5) file usually located at /etc/hosts,
<TR><TD>nis  <TD> -- means hosts map on NIS or YP(4) service,
<TR><TD>dns  <TD> -- means DNS service, and
<TR><TD>sys  <TD id=wrap> -- means using gethostbyname(2) and gethostbyaddr(2)
which usually call system's standard resolver of the host.
</TABLE>
</UL>
</P>
If RESOLV is not specified, "sys" is disabled if the IP-address of the
host of DeleGate is resolvable by "dns".
<BR>

If empty value is specified as RESOLV="" then only hosts listed
in HOSTS parameter can be resolved (this could be useful
when you must hide hosts table for security consideration).
Each resolver can be specified with optional argument like follows:
<P>
<UL>
<TABLE BORDER=0 CELLSPACING=0>
<TR><TD><KBD>cache:/<I>path</I>  </KBD><TD> -- path name of cache directory [$TMPDIR/resolvy]
<TR><TD><KBD>file:/<I>path</I>   </KBD><TD> -- path name of host-name file [/etc/hosts]
<TR><TD><KBD>nis:<I>nisDomain</I></KBD><TD> -- NIS domain name [default domain]
<TR><TD><KBD>dns:<I>dnsHost</I>  </KBD><TD> -- (a list of) DNS server
</TABLE>
</UL>
</P>

<A NAME=RESOLV_routing>
DNS Routing:
A resolver can be applied to specific queries from specific clients.
The optional <I>queryHostList</I> specifies for which hosts or
addresses the resolver is applied.
The optional <I>clientHostList</I> specifies for which client hosts
the resolver is applied.
<P>
Example: selecting DNS servers depending on the inquired host/address
<UL>
<KBD>
RESOLV="cache,dns:{192.168.1.2:8053}:{192.168.*,*.localdomain},dns:192.168.1.1"
</KBD><BR>
// resolve local hosts with DNS sever at 192.168.1.2:8053<BR>
// and resolve others with 192.168.1.1:53<BR>
// this can be decomposed into a set of parameters like follows:<BR>
<KBD>
RESOLV="cache,dns:local-dns:local-hosts,dns:192.168.1.1"<BR>
HOSTLIST=local-dns:192.168.1.2:8053<BR>
HOSTLIST=local-hosts:192.168.*,*.localdomain<BR>
</KBD>
</UL>
<P>
Example: selecting resolvers depending on the inquiring (client) DNS host
<UL>
<KBD>
RESOLV="file:/etc/hosts:localHosts:192.168.*,dns:xx.xx.xx.xx"<BR>
HOSTLIST="localHosts:192.168.*,*.localdomain,*.mydomain"
</KBD><BR>
// queries from local hosts (192.168.*) for "localHosts" are resolved<BR>
// with the file "/etc/hosts", others are resolved with the DNS server
 "xx.xx.xx.xx".
</UL>

<P>
<A NAME=RESOLV_roundrobin>
By default, a connection to a host which has multiple IP addresses
is tried for each address in the order they are defined in each
resolver.   A special parameter HOSTS="*/*/RR" can be added to
specify "<I>Round Robin</I>" where those IP addresses are tried in
round robin order.
</A>
</UL>
</A>


<A NAME=RES_WAIT>
<PRE>
RES_WAIT parameter  ==  RES_WAIT=<I>seconds</I>:<I>hostname</I>
                    --  default: RES_WAIT="10:WWW.DeleGate.ORG"
</PRE>
<UL>
Wait the resolver(s) to be ready before the DeleGate starts the
initialization procedure.  In the initialization, the result value
of host-name resolution can be used as an important configuration
parameter like ones for access control.
The resolver of the host system may take time to be ready after
the system's reboot, and could be unstable typically when the host
address is assigned by DHCP.  Therefore it might be not yet ready
when the DeleGate started.
<BR>
By default, DeleGate waits for 10 seconds until it can resolve
a host name "WWW.DeleGate.ORG" by the given set of resolvers which
is specified by the RESOLV parameter.
You can specify a more appropriate host name or IP address to be
used to detect the readiness of the resolvers.
This feature can be disabled with <KBD>RES_WAIT=0</KBD>.
</UL>
</A>

<A NAME=RES_CONF>
<PRE>
RES_CONF parameter  ==  RES_CONF=<I>URL</I>
                    --  default: RES_CONF="file:/etc/resolv.conf"
                        <I>or from registry</I> (on Windows)
</PRE>
<UL>
Specify where the "resolv.conf" file is.  The file is interpreted
by the DeleGate original resolver named <I>Resolvy</I>.
Resolvy recognizes "nameserver", "domain", "ndots", "search", and
"sortlist" in it.
</UL>
</A>

<A NAME=RES_NS>
<PRE>
RES_NS parameter    ==  RES_NS=<I>nsList</I>
            <I>nsList</I>  ==  <I>dnsServ</I>[,<I>nsList</I>]
           <I>dnsServ</I>  ==  <I>dnsServer</I>[//<I>socksV5Host</I>] | END.
                    --  default: <I>depend on RES_CONF</I>
</PRE>
<UL>
Specify a DNS server to be used: <I>dnsServer</I> is a host name or an
IP-address of the host name DNS server, which may optionally be
followed by port number, like "host:8053" when the port number
is not standard port(53).
With "<I>dnsServer</I>//<I>socksV5Host</I>", a DNS server
beyond a firewall can be referred through the specified Socks V5 server.
The Socks server is specified by its IP address with an optional port
number like "192.168.1.1:2080".
<P>
By default, name servers listed in "<A HREF=#RES_CONF>resolv.conf</A>" are
added to the list of DNS servers to be used. A special <I>dnsServ</I>
name ".END" disables to adding such name servers.  For example,
RES_NS="192.168.1.1,END." means using 192.168.1.1 only regardless of
"resolv.conf".
</UL>
</A>

<A NAME=RES_AF>
<PRE>
RES_AF parameter    ==  RES_AF=<I>afOrder</I>
            <I>afOrder</I> ==  46 | 64 | 4 | 6
                    --  default: 46
</PRE>
<UL>
Specify the ordered set of address families (IPv4 or IPv6) of the address
of the host to be retrieved.  The default value "46" means
retrieving IPv4 address first, and if not found, then IPv6 address next.
</UL>
</A>

<A NAME=RES_RR>
<PRE>
RES_RR parameter    ==  RES_RR=<I>HostList</I>
                    --  default: RES_RR="*"
</PRE>
<UL>
Round robin IP-address-list for the hosts included in the HostList.
Currently, only RES_RR="*" and RES_RR="" are supported.
</UL>
</A>


<A NAME=RES_VRFY>
<PRE>
RES_VRFY parameter  ==  RES_VRFY=""
                    --  default: none
</PRE>
<UL>
With "RES_VRFY=", results of reverse look-up of DNS server is verified.
When an <I>IPaddress1</I> is resolved to <I>Hostname</I>, and when the
<I>Hostname</I> is resolved to <I>IPaddress-list</I> which does not include
the <I>IPaddress1</I>, the verification fail and the result is ignored.
</UL>
</A>


<A NAME=RES_DEBUG>
<PRE>
RES_DEBUG parameter ==  RES_DEBUG=<I>number</I>
                    --  default: none
</PRE>
<UL>
The level of logging for debugging of the built-in resolver.
</UL>
</A><!-- end of PARAMETERS -->
</A>


<A NAME=ProtoList>
<B>PROTOLIST</B>
<PRE>
       <I>ProtoList</I>  ==  [!]<I>protoSpec</I>[,<I>ProtoList</I>]
       <I>protoSpec</I>  ==  <I>protocolName</I>[/[portNumList][/methodList]]
</PRE>
<UL>
A ProtoList is a list of protocol names.
Reserved name "*" means all of protocols.
If "!" or "-" is prefixed,
the protocol is excluded from the protocol list.  
</UL>
</A>


<A NAME=HostList>
<B>HOSTLIST</B>
<PRE>
        <I>HostList</I>  ==  [!][-<I>iType</I>]<I>hostSpec</I>[,<I>HostList</I>]
           <I>iType</I>  ==  {h|a|c|*}/[<I>iType</I>]
        <I>hostSpec</I>  ==  [{<I>userList</I>}@]<I>hostSpec</I>[/<I>netMask</I>]
        <I>userList</I>  ==  <I>userNamePattern</I>[,<I>userNamePattern</I>]*
        <I>hostSpec</I>  ==  <I>hostNamePattern</I> | <I>hostAddrPattern</I>
 <I>userNamePattern</I>  ==  [*]<I>uname</I>[*]
 <I>hostNamePattern</I>  ==  [*]<I>hname</I>[*]
 <I>hostAddrPattern</I>  ==  <I>IPaddressPattern</I> | <I>IPrange</I>
         <I>netMask</I>  ==  <I>IPaddress</I> | <I>maskLength</I>
</PRE>
<UL>
A HostList is a list of hosts (by name or address)
to be used for matching to examine whether a certain host is included
in the list or not.
Each host (<I>hostSpec</I>)
is optionally prefixed with a list of users (<I>userList</I>),
and optionally followed by a <I>netMask</I>.
<DL>
<P><DT>TYPE OF IDENTITY<DD>
A <I>hostSpec</I> "<I>person</I>@<I>place</I>" represents following identities:
<UL><DL>
<DT> [<KBD>-h/</KBD>] [<I>Ident</I>@]<I>peerHost</I>
 -- peer host's identity (client, server or proxy)
<DD>
The name or address of the host matches with <I>peerHost</I>,
and if <I>Ident</I>@ part is specified,
the name of the owner of the connection, detected automatically
by the <A HREF=#Ident>Identification</A> protocol, matches with <I>Ident</I>.
</DD>

<A NAME=authident>
<DT> [<KBD>-a/</KBD>] <I>authUser</I>@<I>authHost</I>
 -- authenticated identity
<DD>
The user of the client is authenticated as <I>authUser</I>
(showing the name with an appropriate password)
by an authentication server <I>authHost</I>
(specified as <A HREF=#AUTHORIZER>AUTHORIZER</A>=<I>authHost</I>)
</DD>
</A>

<DT> [<KBD>-c/</KBD>] <I>person</I>@<I>domain</I>
 -- certificated identity
<DD>
The E-mail address of the client's user is given as
/Email=<I>person</I>@<I>domain</I>/
in a client's certificate (which is passed over <A HREF=#serv_SSL>SSL</A>).
</DL></UL>

<A NAME=iType TITLE="identity type">
Implicitly, A <I>hostSpec</I> like "<I>host</I>" without "<I>user</I>@"
part matches only with peer host's identity
while "<I>user</I>@<I>host</I>" matches with any kind of identities.
By prefixing -<I>iType</I> before <I>hostSpec</I>, identities to be
matched can be specified explicitly.  for example:
<UL>
<KBD>user@host</KBD>
 -- matches if at least one of identities is "user@host"
<BR>
<KBD>-h/user@host</KBD>
 -- matches if peer host's identity is "user@host"
<BR>
<KBD>host</KBD>
 -- matches if peer host's identity is "host"
<BR>
<KBD>-*/host</KBD>
 -- matches if at least one of identities is "*@host"
<BR>
<KBD>-a/host</KBD>
 -- matches if authenticated identity is "*@host"
<BR>
<KBD>-a/c/host</KBD>
 -- matches if authenticated or certificated identity is "*@host"
<BR>
<KBD>-a/*</KBD>
 -- matches if authenticated successfully
<BR>
</UL>
</A>

<P><DT>WILDCARD ( * )<DD>
A set of hosts belonging to a domain or a network can be represented
as a single <I>hostSpec</I> with wild-card notation.
You can prefix or postfix wild-card character "*" to a hostname
like "*.com" or "*.delegate.org" or "www.*".

As a special case, <I>hostSpec</I> which begins with "*." like
"*.<I>domain</I>" matches with "<I>domain</I>" as a hostname
as well as ordinary hostnames like "xx.<I>domain</I>" or "yy.xx.<I>domain</I>"
(since DeleGate/6.1.18).

IP-address range, which may represent a network,
can be specified like 192.168.[0-255], 192.168.1.[32-63].
These range can be written as 192.168.0.0/16 and 192.168.1.32/27.
In IP-address notation, wild-card character  "*" means [0-255],
thus "192.168.*" is equals to 192.168.[0-255].
</DD>

<A NAME="HostListNegation" TITLE="Negation">
<P><DT>NEGATION ( ! )<DD>
If "!" is prefixed to a <I>host</I>,
it means that the host is excluded from the list.
All of elements in the list are scanned from the first one to the last one.
Thus once included (excluded) name may be excluded (included)
in succeeding list.
For example, for a HostList like follows: 
<P><UL>
  "*.dom,!*.xx.dom,*.yy.xx.dom"
</UL><P>
a host named "host.yy.xx.dom" matches with the first <I>hostSpec</I>,
but excluded by the second one, but included again by the third one.
If the first <I>host</I> in a HostList is with "!", it means
exclusion from the universe ("*", that is any host), that is,
<KBD>"!host, ..."</KBD> is regarded as <KBD>"*,!host, ..."</KBD>
</DD>
</A>

<P><DT>NETMASK ( <I>host</I>/<I>mask</I> )<DD>
Specifying a <I>netMask</I>, you can check only a part of address,
the network address part typically.
The <I>netMask</I> can be specified in one of following formats;
<P>
<DL>
<DT><KBD>/24</KBD>, <KBD>/28</KBD>, ...  length of mask bits
<DT><KBD>/FFFFFF00</KBD>, <KBD>/FFFFFFF0</KBD>, ...  hexadecimal notation
<DT><KBD>/255.255.255.0</KBD>, <KBD>/255.255.240.0</KBD>, ...  dot notation
<DT><KBD>/@A</KBD>, <KBD>/@B</KBD> or <KBD>/@C</KBD> ...
 address class mask.
<DD><KBD>@A</KBD>, <KBD>@B</KBD> and <KBD>@C</KBD> represent
<KBD>/8</KBD>, <KBD>/16</KBD> and <KBD>/24</KBD> respectively.
This notation can be followed by the number of bits for subnets;
for example <KBD>/@B4</KBD> means class B network
divided into sixteen subnets.
<DT><KBD>@</KBD> ... the default network mask
<DD>represents one of <KBD>/@A</KBD>, <KBD>/@B</KBD> or <KBD>/@C</KBD>
depending on the class of IP-address of the host to be masked
<DT><KBD>.</KBD> ... narrower default network mask
<DD>similar to "@"
but represents "/24" when it is applied to class-A IP-addresses.
For an IPv6 address, the default mask is "ffff_ffff_ffff_ffff__"
which represents a mask of 64bits "FFFF:FFFF:FFFF:FFFF::".
</DL>

<P><DT>USER LIST ( {<I>userList</I>}@<I>host</I> )
<DD>For a srcHostList (i.e. HostList concerning client hosts),
list of user names (<I>userList</I>) can be prefixed to a host name
like {user1,user2,...}@host. 
The negate symbol "!" have the same meaning with that in a HostList.
Note that !user@host is different from {!user}@host;
the former excludes user@host,
but the latter means {*,!user}@host thus includes *@host except user@host.
The special user name "?" matches with users whos names are not
IDENTified with identd.<P>
Example: inhibit access from unknown hosts or from unknown users
<UL>
<KBD>
RELIABLE="{!?,!?@*}"
</KBD>
</UL>
</DD>

<A NAME=portList TITLE="Port list">
<P><DT>PORT LIST ( <I>host</I>:{<I>portList</I>} )
<UL>
For a dstHostList  (i.e. HostList concerning server hosts), a list of
port numbers (<I>postList</I>) can be postfixed to a host,
to make matching by port number as well as host name/address.
<P>
Example: conditional filtering using <A HREF="#CMAP">CMAP</A>
 <UL>
 <KBD>
 CMAP="sslway:FSV:*:{*:{563,636,990,992,995}}:*"
 </KBD>which is similar to<BR>
 <KBD>
 CMAP="sslway:FSV:nntps,ldaps,ftps,telnets,pop3s:*:*"
 </KBD>
 </UL>
</UL>
</A>

<P><DT>SPECIAL HOST NAMES<DD>
There are special host names which are substituted with real host
names at runtime.
<P>
<DL>
<DT> "."
<DD> the host where the DeleGate is running.
<DT> "-"
<DD> identical to "." if the host has unique IP address (network
interface), but if it have multiple IP addresses, it will
be the IP address from which the client connected to this DeleGate.
<DT> ".o"
<DD> identical to "." if the host has unique IP address, but if
it have multiple network interface, outgoing 
network interface
</DD>
<A NAME=localnet TITLE=".localnet">
<DT>".localnet"
<DD>
represents <KBD>"localhost,./.,-/.,.o/."</KBD> by default.
It can be redefined by the <A HREF="#HOSTLIST">HOSTLIST</A> parameter
as HOSTLIST=.localnet:<I>HostList</I>.
</DD>
</A>
<DT> ".C" or "-C"
<DD> the client host which may be useful to restrict access
from a client only to the client (network).
<DT> "?"
<DD> matches any "<I>unknown hosts</I>" of which name or address is not
known by resolvers (listed in <A HREF="#RESOLV">RESOLV</A>).
</DL>

<P><DT>DISABLING NAME RESOLUTION ( -<I>host</I> )<DD>
If a hostname (or a IP-address) is prefixed with "-" like "-hostname"
("-192.168.1.1"), then no name resolution (reverse resolution) will be
tried for the hostname (IP-address).  This will avoid wasting time in
resolution trial for a never resolvable hostname (IP-address).

<P><DT>ADDRESS TYPE ( _4. | _6. )<DD>
<!--
If "_4." or "_6." is prefixed to a <I>host</I>,
it means that the address of the <I>host</I> is in IPv4 or IPv6 respectively.
-->
<KBD>"_4.*"</KBD> matches any IPv4 addresses while
<KBD>"_6.*"</KBD> matches any IPv6 addresses.
These can be used for routing or access control based on address types.

<P><DT>AGENT CONDITION ( -A/<I>agentNamePattern</I> )<DD>
A pseudo host name pattern with prefix "-A/" at the top of it is used to
specify the User Agent of the client.
<DD>
<P>
Example:
<UL>
RELIABLE="-A/Mozilla/4,!-A/MSIE 5" ... which is similar to<BR>
RELIABLE=.realmozi4 HOSTLIST=".realmozi4/A:Mozilla/4,!MSIE 5"<BR>
</UL>
</DD>

<A NAME="TimeCondition">
<P><DT>TIME CONDITION ( -T.<I>period</I> )<DD>
A pseudo host name pattern with prefix "-T." at the top of it is used to
specify a time period in a day.<BR>
<DD>
"-T.<I>period</I>"
matches if the current time is in the specified time <I>period</I>,
where <I>period</I> is represented as "<I>hour1</I>-<I>hour2</I>"
which means "from <I>hour1</I>:00:00 to <I>hour2</I>:59:59".<BR>
<P>
Example:
<UL>
<KBD>
PERMIT="*:-T.9-16:<I>hostList1</I>" PERMIT="*:-T.17-8:<I>hostList2</I>"<BR>
</KBD>
// <I>hostList1</I> is permitted during office hours whereas<BR>
// <I>hostList2</I> is permitted non-office hours.
</UL>
<P>
The complete format of <I>period</I> is like this:
[w<I>W</I>]<I>HH</I>[<I>MM</I>][-<I>HH</I>[<I>MM</I>]].
A time period in a week is represented with "w<I>W</I>" where <I>W</I>
expresses a day in a week ranging from "0" to "6" according to Sunday
through Saturday. Sunday can be expressed as "7" too for convenience.
<P>
Example:
<UL>
<KBD>-T.w5-0</KBD> // Friday through Sunday<BR>
<KBD>-T.w5-7</KBD> // Friday through Sunday<BR>
<KBD>-T.w51730-10830</KBD> // from 5:30pm on Friday to 8:30am on Monday
</UL>
</DD>
</A>

<A NAME="HostListComposite" TITLE="Composite operators">
<P><DT>COMPOSITE OPERATORS ( &, |, ! )<DD>
As explained above, the meaning of a comma (,)
in HostList like "A,B" is not AND nor OR.
Operators like AND, OR and NOT operators are provided as
a special member of a list.
<P>
<DL>
<DT> "&"
<DD> AND operator used as "<I>hostList</I>=A,&,B" where when A turn to be
false, the <I>hostList</I> as a whole turns to be false without
evaluating B.  Otherwise B must be true to be true as a whole.
<DT> "|"
<DD> OR operator used as "<I>hostList</I>=A,|,B" where when A turns to be
true, the <I>hostList</I> as a whole turns to be true without
evaluating B.  Otherwise B must be true to be true as a whole.
<DT> "!"
<DD> NOT operator used as "A,!,B" where the result of A is
negated, and succeed evaluation of B if it exists.
</DL>
<P>
Example:
<UL>
<KBD>
PERMIT="*:*:-T.9-16,&,<I>hostList1</I>" PERMIT="*:*:-T.17-8,&,<I>hostList2</I>"<BR>
</KBD>
// the same meaning with the above example.
</UL>
</DD>
</A>

</DL>
</UL>
</A>


<A NAME="Substitution">
<A NAME="term_SUBSTITUTION" TITLE="Parameter Substitution">
<B>PARAMETER SUBSTITUTION</B>
<UL>
There is no format of <I>configuration file</I> with some syntax sugar
for DeleGate (yet),
but there is a simple recursive substitution mechanism instead,
to assemble hierarchical and possibly distributed parts of parameters 
into a single list of parameters (or options).
<P>
Options and parameters can be loaded from external
"<I>substitution resources</I>".
An option like "+=<I>file</I>" is substituted by a list of options enumerated
in the resource named "<I>file</I>".
An option like "<I>name</I>=+=<I>file</I>" is substituted
by a list of "<I>name</I>=<I>value</I>"
where the "<I>value</I>" is enumerated in the "<I>file</I>".
Similarly an option like "<I>name</I>=<I>xxx</I>:+=<I>file</I>" is substituted
by a list of "<I>name</I>=<I>xxx</I>:<I>value</I>".

<P>
<A NAME=CryptedParams>
A <I>substitution resource</I> can be given in an encrypted format.
Encrypted data can be directly represented in the string of format
as "+=enc:ext::XXXX:" in which the part of XXXX contains the encrypted data.
This format of data is created with "-Fenc" option of DeleGate.

When it is named with the suffix "<KBD>.cdh</KBD>" as "+=conf.cdh",
it is decrypted by "Credhy" using the passphrase for decryption
which is specified as the password of
the <A HREF=#EncryptedConf>"config" user</A>.
</A>

<P>
Substitution can be done recursively.  In this case, a relative resource
name is searched in <A HREF="#DGPATH">DGPATH</A>
or <A HREF="#LIBPATH">LIBPATH</A>.
By default, <KBD>DGPATH='+:.:${HOME}/delegate'</KBD>
where "+" stands for the place where the "<I>caller</I>" resource is.
For example, if "+=file2" is referred from caller file "/local/etc/file1",
the "file2" will be searched first as "/local/etc/file2".
A resource name can be specified in full URL like
"+={file:/local/etc/file1}" or "+={http://host/file}".

<P>
<UL>
<PRE>
       <I>paramRef</I> ==  +=[<I>URL</I>][?<I>label</I>,[<I>label</I>]*]

      <I>paramList</I> ==  <I>line</I>
                    <I>line</I>
                    ...

  <I>paramListPart</I> ==  CASE <I>label</I>
                         <I>paramList</I>
                    ESAC
</PRE>
</UL>

<P>
Substitution resources are the list of options (or parameters)
where each line stands for an option (or a parameter).
In each line, strings after sharp character(#) will be ignored
as a comment.
White space characters (SPACE, TAB, LF and CR) at the beginning
or the ending of each line are ignored.
Single quote(') and double quote(") are stripped.
Back slash character(\) let the succeeding character be as is.
<P>
Example:
The following five examples have the same meaning with each other.
<UL>
<P>
<KBD>
PERMIT=a:b:c PERMIT=a:b:d PERMIT=a:e:f PERMIT=x:y:z ...
</KBD>

<P>
<DL>
<DT><KBD>+=parameters</KBD>
<DT>[content of parameters]
<DD>
<KBD>
PERMIT=a:b:c<BR>
PERMIT=a:b:d<BR>
PERMIT=a:e:f<BR>
PERMIT=x:y:z<BR>
...<BR>
</KBD>
</DL>

<P>
<DL>
<DT><KBD>PERMIT=+=permits</KBD>
<DT>[content of permits]
<DD>
<KBD>
a:b:c<BR>
a:b:d<BR>
a:e:f<BR>
x:y:z<BR>
</KBD>
...
</DL>

<P>
<DL>
<DT><KBD>PERMIT=a:b:+=abclients PERMIT=+=others</KBD>
<DT>[content of abclients]
<DD>
<KBD>
c<BR>
d<BR>
</KBD>
<DT>[content of others]<BR>
<DD><KBD>
a:e:f<BR>
x:y:z<BR>
</KBD>
...
</DL>

<P>
<DL>
<DT><KBD>PERMIT=+=permits<BR></KBD>
<DT>[content of permits]<BR>
<DD>
<KBD>
<DL>
<DT>PERMIT=a:b:+=?abclients<BR>
<DT>PERMIT=+=?others<BR>
<DT>CASE abclients<BR>
<DD>
  c<BR>
  d<BR>
<DT>ESAC<BR>
<DT>CASE others<BR>
<DD>
  a:e:f<BR>
  x:y:z<BR>
  ...<BR>
<DT>ESAC<BR>
</DL>
</DL> </KBD>

<BR>
</UL>

<P>
Substitution resources will be reloaded when the DeleGate
<A HREF="#RESTART">restart</A>
receiving a SIGHUP signal or by "-restart" action in CRON parameter.

<P>
Another substitution is in the form "<I>name</I>=-=<I>URL</I>" which loads the
content of URL into a temporary file on local file system (under ACTDIR),
then the parameter is rewritten to "name=/path/of/temporary-file".
This will be useful when you wish to pass remote resources to CGI or
CFI programs,
like "<A HREF="#opt_-e">-e</A>CONFIGDATA=-=http://server/configData",
then those programs will be given an environment variable named CONFIGDATA
of which value is a temporary file name containing the content of
"http://server/configData".
</UL>
</A>
</A>

<A NAME="CFIscript" TITLE="CFI and CFI script">
<P>
<B>CFI AND CFI SCRIPT</B>
<UL>
Communication between client and DeleGate or between DeleGate and server
can be filtered or translated by user defined
filter programs attached to DeleGate using a simple scheme named
CFI (Common Filter Interface).
Existing filter programs, from standard input to standard output,
can be used as a CFI program without modification.
The usage of CFI is controlled by parameters like following:

<UL><PRE><I>filterName</I>="<I>filterSpec</I>"
CMAP="<I>filterSpec</I>":<I>filterName</I>:<I>connMap</I>

  <I>filterName</I>  ==  FCL | FTOCL | FFROMCL |
                  FSV | FTOSV | FFROMSV |
                  FMD | FTOMD | FFROMMD 
  <I>filterSpec</I>  ==  <I>filterCommand</I> | <I>CFIscriptName</I>
                  | tcprelay://<I>host</I>:<I>port</I>
</PRE></UL>

<I>filterName</I> is named as
<KBD>F<I>XX</I></KBD>, <KBD>FTO<I>XX</I></KBD> and <KBD>FFROM<I>XX</I></KBD>
where <KBD><I>XX</I></KBD> is one of
<KBD>CL</KBD> (client), <KBD>SV</KBD> (server) and <KBD>MD</KBD> (MASTER-DeleGate).
Filter commands for <KBD>F<I>XX</I></KBD> are bidirectional filter
given file descriptor 0 bound for the client,
and file descriptor 1 bound for the DeleGate.
Filters commands for <KBD>FTO<I>XX</I></KBD> and <KBD>FFROM<I>XX</I></KBD>
getting input from standard input and put output to standard output
which is bound for <KBD><I>XX</I></KBD>.
A unidirectional filter at a remote host can be used by connecting it on TCP
by "tcprelay://<I>host</I>:<I>port</I>"
<P>
<A NAME=cond-filter TITLE="Conditional Filter">
A filter can be applied conditionally
based on circuit level information,
using <A HREF="#CMAP">CMAP</A> parameter like follows:
<UL>
CMAP=<I>filterSpec</I>:<I>filterName</I>:<I>ProtoList</I>:<I>dstHostList</I>:<I>srcHostList</I>
</UL>
For example, CMAP="sslway:FSV:telnet:hostA:*"
means applying SSLway filter only
when connecting to the Telnet server at hostA.
</A>
<P>
For <KBD>FTO<I>XX</I></KBD> and <KBD>FFROM<I>XX</I></KBD> filters,
CFI script enables selecting an appropriate filter
to be applied to each data depending on the type of data. 
Instead of direct usage of a filter program like
<KBD>FTOCL=<I>filterCommand</I></KBD>, specify
<KBD>FTOCL=<I>filter.cfi</I></KBD> where filter.cfi is a file
in the CFI script format.
Or a CFI script can be loaded from remote host like
<KBD>FTOCL=<I>URL</I></KBD> via HTTP or FTP.
When the file name of CFI scripts or a filter command referred
in the script is specified in relative path name,
it is searched in <A HREF="#LIBPATH">LIBPATH</A>.

<A NAME="CFI-script" TITLE="CFI script">
<P>
<B>CFI script</B>
<P>
The CFI script is a simple script to select an appropriate filter
to be applied to a message data relayed on DeleGate, depending on
the type of data, the server name, the type of client, and so on.
A CFI script is text data which
starts with a magic string <KBD>"#!cfi"</KBD> and
contains more than one filter specifications
which are separated by <KBD>"--"</KBD> with each other.

<P>
<PRE>
  <I>CFI script</I>   == "!#cfi" NL <I>filterUnit</I> [ "--" NL <I>filterUnit</I> ]*
  <I>filterUnit</I>   == <I>filterRule</I> [ <I>filterRule</I> ]*
  <I>filterRule</I>   == <I>matchingRule</I> | <I>rewriteRule</I> | <I>filterSpec</I>
  <I>matchingRule</I> == <I>matchingName</I> ":" <I>ruleBody</I>
  <I>matchingName</I> == <I>MIMEheader</I> | <I>X-header</I> | <I>CGIENV</I>
  <I>MIMEheader</I>   == "Content-Type" | "User-Agent" | ...
  <I>X-header</I>     == "X-Status-Ver" | "X-Status-Code"
                | "X-Request-Method" | "X-Request-Ver"| "X-Request-URL" | ...
  <I><A HREF=http://hoohoo.ncsa.uiuc.edu/cgi/env.html>CGIENV</A></I>       == "REQUEST_METHOD" | "SERVER_PROTOCOL" | "SERVER_NAME"
                | "PATH_INFO" | "PATH_TRANSLATED" | "HTTP_USER_AGENT" | ...
  <I>rewriteRule</I>  == <I>Action</I> "/" <I>MIMEheader</I> : <I>ruleBody</I>
  <I>Action</I>       == "Output" | "Remove"
  <I>filterSpec</I>   == <I>filterType</I> ":" <I>ruleBody</I>
  <I>filterType</I>   == "Body-Filter" | "CGI" | "Header-Filter"
                | "MIME-Filter" | "Message-Filter"
  <I>ruleBody</I>     == <I>string</I> NL [ SP <I> string</I> NL ]*
</PRE>
<P>
<U>Input Format</U>:
<BR>
The input data to CFI script is a message of application protocol in
MIME format preceded with a request or a response status line of the
application protocol (HTTP, SMTP, POP, NNTP).
A MIME message is composed with a header and a body separated with
an empty line.
<PRE>
  <I>CFIinputMessage</I> == <I>statusLine</I> <I>MIMEheader</I> NL <I>MIMEbody</I>
</PRE>
Example: a simple HTTP response message
<UL>
<PRE>
<KBD>
HTTP/1.0 200 OK           ... response status line
Content-Type: text/html   ... header
Content-Length: 20        ... header
                          ... header/body separator
body of the message       ... body
</KBD>
</PRE>
</UL>
<P>
<U>Matching Rule</U>:
<BR>
A <I>matchingRule</I> indicates matching the
<KBD><I>ruleName</I>:<I>ruleBody</I></KBD> to the input header.
It matches when the input message has a <I>ruleName</I> header with
a field body matches with <I>ruleBody</I>.
If at least one of matching rules turns to be true,
then the <I>filterUnit</I> is adopted.
If no matching rule is included in a <I>filterUnit</I> then
the <I>filterUnit</I> is adopted unconditionally.

Currently, only a limited set of MIME headers (in request or response
message) can be used for the matching.
Also, some extended headers can be used to match with information not
included in the original header (ex. "X-Status-Code" which means
status code in response message).
Matching with <A HREF=http://hoohoo.ncsa.uiuc.edu/cgi/env.html>CGI</A>
environment variables.
<P>
Example: a matching rule<UL><KBD>
  #!cfi<BR>
  HTTP_USER_AGENT: MSIE<BR>
  SERVER_HOST: www1.dom1<BR>
  SERVER_HOST: www2.dom2<BR>
  X-Status-Code: 200<BR>
  Content-Type: text/html<BR>
  Content-Type: text/plain<BR>
  Body-Filter: ...<BR>
</KBD></UL>
<P>
<U>Rewriting Rule</U>:
<BR>
A <I>rewriteRule</I> with a prefix "<I>Action</I>/" to a
<I>ruleName</I>:<I>ruleBody</I> specifies some simple rewriting
using <I>ruleBody</I> data for relevant <I>ruleName</I> field.
"Output/<I>ruleName</I>:<I>ruleBody</I>" indicates appending (or replacing)
a <I>ruleName</I>:<I>ruleBody</I> field into the header.
"Remove/<I>ruleName</I>:<I>ruleBody</I>" indicates removing header fields
with name <I>ruleName</I> and body matches to <I>ruleBody</I>.

<P>
<U>Filter Specification</U>:
<BR>
A <I>filterSpec</I> specifies a filter to be applied to the input data.
The whole or a part of input message will be passed to
the standard input of the filter program, then the output from the
standard output of it will be forwarded to the destination
(client or server) instead of the original input message.
<PRE>
  Body-Filter:    filter for <I>MIMEbody</I>
  CGI:            filter for <I>MIMEbody</I>
  Header-Filter:  filter for <I>MIMEheader</I>
  MIME-Filter:    filter for <I>MIMEheader</I> + <I>MIMEbody</I>
  Message-Filter: filter for <I>statusLine</I> + <I>MIMEheader</I> + <I>MIMEbody</I>
</PRE>
For filters of any type, the set of
<A HREF=http://hoohoo.ncsa.uiuc.edu/cgi/env.html>CGI</A>
environment variables is passed.
In addition, CFI origin environments variables are passed including
"<KBD>SERVER_HOST</KBD>" (the name of the destination server),
"<KBD>REQUEST_URL</KBD>" (the URL of the request).
<P>
For filters of "Body-Filter" or "CGI",
the "Content-Length" header in the forwarded message will be
adjusted to indicate the size of the body part after the filtering.
The output of "CGI" filter must preceded with the status header
of <A HREF=http://hoohoo.ncsa.uiuc.edu/cgi/out.html>CGI output</A>.
<P>
For filters of "Header-Filter",
the header part of a message will be passed to and from the filter.
The <I>start-line</I> in the HTTP message (Request-Line or Status-Line)
will be passed as a header field prefixed with
"Request-Line:" or "Status-Line:".
<P>
For filters of "MIME-Filter",
the whole of the MIME message consists of a header and a body is passed
to and from the filter.
<P>
For filters of "Message-Filter",
the whole message of the application protocol is passed to and from the filter
where each message consists of a MIME message prefixed with a line
representing request or response status in the application protocol.
<!--
Filter/Body: filter
Filter/Header: filter
-->

<P>
Example: rewriting HTTP response messages
<UL><KBD>
SERVER=http FTOCL=test.cfi<BR>
<BR>
[content of test.cfi]<BR>
#!cfi<BR>
Content-Type: text/html<BR>
Body-Filter: sed 's/<I>string1</I>/<I>string2</I>/'<BR>
--<BR>
Content-Type: image/gif<BR>
Output/Content-Type: image/jpeg<BR>
Body-Filter: gif2jpeg<BR>
</KBD>
</UL>

<P>
Example: dump available headers and environment variables
<UL><KBD>
#!cfi<BR>
Header-Filter: -tee-n-v /dev/tty<BR>
Body-Filter: env|sort > /dev/tty; cat<BR>
</KBD></UL>
</A>

</UL>
</A>


<A NAME=DGproxy TITLE="Proxying by URL Redirection">
<P>
<B>PROXYING BY URL REDIRECTION</B>
<P>
<UL>
DeleGate with RELAY="delegate" provides a special proxying without
changing "proxy configuration" in browsers.
When the URL of such DeleGate is http://<I>delegate</I>/,
a user can access target <I>URL</I> via the DeleGate
by giving a URL like http://<I>delegate</I>/-_-<I>URL</I> to the browser.
A request message for the URL from the client will be in form of
/-_-<I>URL</I> which is regarded as a request for <I>URL</I>
by DeleGate.
Then the DeleGate rewrites a URL included in a response messages to client
so that the access to the URL is directed to the DeleGate again.
This <I>redirection</I> is achieved by prefixing the URL of DeleGate
(http://<I>delegate</I>/) and "-_-" sign before original <I>URL</I> like
http://<I>delegate</I>/-_-<I>URL</I>.

<P>
<KBD>
<UL>
U->C: </KBD><I>user opens</I><KBD> http://delegate/-_-http://www/path1<BR>
C->D: GET /-_-http://www/path1<BR>
D->S: GET /path1<BR>
D<-S: HREF=/path2<BR>
C<-D: HREF=http://delegate/-_-http://www/path2<BR>
U->C: </KBD><I>user clicks the anchor</I><KBD><BR>
C->D: GET /-_-http://www/path2<BR>
D->S: GET /path2<BR>
S->D: HREF=ftp://ftp/path<BR>
D->C: HREF=http://delegate/-_-ftp://ftp/path<BR>
</UL>
</KBD>

<P>
Originally, this redirection mechanism was implemented for Gopher proxy,
and extended to HTTP protocol,
then extended to a generic MOUNT mechanism.
Now almost the same effect with "-_-" redirection can be emulated
with a MOUNT parameter like follows, allowing to replace "-_-" with
an arbitrary string.
<P>
<UL>
<KBD>
MOUNT="/-_-* *"
</KBD>
</UL>

<P>
You can write a DeleGate <I>switching table</I> in HTML.
Suppose that you have two DeleGate hosts connected to different network
provider each other, and you want to select one of them explicitly
but without changing configuration of your browser
and without typing a lengthy URL prefixed with "http://<I>delegate</I>/-_-".
You can write a table in HTML to switch DeleGate like this:  
<P>
<UL>
&lt;A HREF="http://proxy1:8080/-_-http://www.w3.org/"> W3C via firewall1 &lt;/A><BR>
&lt;A HREF="http://proxy2:8080/-_-http://www.w3.org/"> W3C via firewall2 &lt;/A>
</UL>
<P>
This table works independently of if the client is using DeleGate
or not,
because DeleGate does not do URL redirection in response message
described above if the URL is already redirected like above.
<P>
Right after the -_- mark, optional "/Modifier/" form can be inserted
as follows:
<UL>
http://delegate/-_-/Modifier/URL
</UL>

Modifier can be a list of multiple Modifiers separated each other by
by comma (,) character.
<UL>
<DL>
<DT>cc.<I>outCode</I>[.<I>inCode</I>]
<DD>the character code of text data toward the client,
<KBD>"cc.JIS"</KBD> for example.
<DT>F<I>flags</I>
<DD><I>flags</I> is a list of flag characters
"C" to disable cache,
"N" to force using not name but address overriding DELEGATE parameter,
"J" to make JIS (ISO-2022-JP) output overriding CHARCODE parameter,
and so on.
</DL>
</UL>
</UL>
</A>


<A NAME=ProtoSpec TITLE="Protocol Specific Issue and Examples">
<B>PROTOCOL SPECIFIC ISSUE AND EXAMPLES</B>
<P>
Common Notation
<UL>
<P>
<DL>
<DT># delegated ...
<DD>implies invoking DeleGate by super-user to use a privileged port number
<DT>% delegated ...
<DD>implies invoking DeleGate by non super-user
<DT><KBD><I>firewall</I></KBD>% delegated ...
<DD>implies running DeleGate on a host belongs to your site
and reachable to/from internet
<DT><KBD><I>internal</I></KBD>% delegated ...
<DD>implies running DeleGate on a internal host
in your site which is isolated from internet
<DT><KBD><I>external</I></KBD>% ...
<DD>implies doing something on a host external to your site
</DL>
</UL>


<A NAME=serv_tcprelay TITLE="TCPrelay">
<P>
<B>TCPrelay</B>
<UL>
DeleGate with a SERVER=tcprelay parameter
relays communication between a client and a server
on a single TCP connection
without interpreting what is transmitted on it.
Thus an arbitrary application protocol on TCP,
even if it is not in supported protocol list of DeleGate,
can be relayed by SERVER=tcprelay.

But value added services, including caching, mounting and logging,
are not available in this case.
Connecting to arbitrary destination servers depending on a request from
a client is not possible.
Application protocols which dynamically create other connections besides
the main connection, like FTP, are not relayable.
Application protocols which exchange some kind of name depends on
an origin server on the protocol, like a full URL in HTTP,
are not relayable too. 
<P>
Example: two proxies on TCP with similar function
<UL>
# delegated -P25 SERVER=smtp://mailserver<BR>
# delegated -P25 SERVER=tcprelay://mailserver:25
</UL>
</UL>
</A>

<A NAME=serv_udprelay TITLE="UDPrelay">
<P>
<B>UDPrelay</B>
<UL>
DeleGate with a SERVER=udprelay parameter
relays communication between a server and clients on UDP
without interpreting what is transmitted on it.
It has similar merits/demerits to tcprelay for TCP.
Also application protocols on which routing information are exchanged,
like CU-SeeMe, are not relayable with udprelay.
<P>
Example: two proxies on UDP with similar function
<UL>
# delegated -P53 SERVER=dns://nameserver<BR>
# delegated -P53 SERVER=udprelay://nameserver:53
</UL>
<P>
Example: a gateway between UDP and TCP
<UL>
// UDP clients and a TCP server<BR>
<KBD># delegated -P53 SERVER=udprelay://nameserver:53 CONNECT=tcp</KBD><BR>
// TCP clients and a UDP server<BR>
<KBD># delegated -P53/tcp SERVER=udprelay://nameserver:53</KBD><BR>
</UL>
<P>
A pair of gateways like above can be used to convey UDP packets over TCP
connections, but such relaying (tunneling) is realized more efficiently
using <A HREF=#UdpOverTcp>SockMux</A> with a single TCP connection.
</UL>
</A>

<A NAME=serv_DGAuth TITLE="DGAuth server">
<P>
<B>DGAuth server</B>
<P>
<UL>
"DGAuth" server by DeleGate provides Digest Authentication functionality
remotely, over an experimental "DGAuth" protocol.
<P>
Example: DGAuth-DeleGate server and its client<UL>
<KBD>
hostS% delegated SERVER=dgauth -P8787<BR>
hostC% delegated SERVER=http -P8080 AUTHORIZER=<A HREF=#dgauth>-dgauth</A>//hostS..8787
</KBD>
</UL>
<P>
Example: DGAuth-DeleGate server and its client on the same host<UL>
<KBD>
hostX% delegated SERVER=dgauth<BR>
hostX% delegated SERVER=http -P8080 AUTHORIZER=<A HREF=#dgauth>-dgauth</A>
</KBD>
</UL>
<P>
A DGAuth server receives a set of components to be used to calculate
digest for each application protocol, then return the digest, as follows.
<UL>
<KBD>
<DL>
<DT>Request:
<DD>
  HTTP <I>user</I> <I>nonce</I> <I>realm</I> <I>method</I> <I>uri</I><BR>
  APOP <I>user</I> <I>nonce</I> [<I>realm</I>] (not used currently)<BR>
</DD>
<DT>Response:
<DD>
  200 <I>digest</I><BR>
  501 syntax error<BR>
  502 unknown user<BR>
</DD>
</DL>
</KBD>
</UL>
</UL>
</A>

<A NAME=serv_PAM TITLE="PAM server">
<P>
<B>PAM server</B>
<P>
<UL>
PAM server by DeleGate provides PAM (Pluggable Authentication Modules)
functionality remotely,
over an experimental protocol compatible with HTTP (PAM/HTTP).
<P>
Example: PAM-DeleGate server and its client<UL>
<KBD>
hostX% delegated -P8686 SERVER=httpam<BR>
hostY% delegated -P8023 SERVER=telnet AUTHORIZER=-pam//hostX/passwd
</KBD>
</UL>
<P>
Example: PAM-DeleGate server and its client communicating over SSL<UL>
<KBD>
delegated hostX% -P8686 SERVER=httpam FCL=sslway<BR>
delegated hostY% -P8023 SERVER=telnet AUTHORIZER=-pam//hostX/passwd
<A HREF=#cond-filter>CMAP=sslway:FSV:pam</A>
</KBD>
</UL>
<P>
Note that most of PAM authentications need to be executed under the
privilege of superuser on Unix (with OWNER="root" option).
But you can avoid running your PAM-DeleGate server with superuser privilege by
installing external program "dgpam" under <A HREF=#subin>DGROOT/subin/</A>.
<P>
The default port number of the experimental PAM/HTTP server is 8686.
Other ports can be specified as
<A HREF=#AUTHORIZER>AUTHRIZER</A>=-pam//<I>host</I>..<I>port</I>,
for example as AUTHORIZER="-pam//hostX..8765/passwd".
<P>
PAM/HTTP protocol uses the format of HTTP compatible request/response
messages as follows.
<UL>
<KBD>
<DL>
<DT>Request:
<DD>
  GET /-/pam/<I>service</I>/auth HTTP/1.0<BR>
  Authorization: Basic BASE64of(<I>User</I>:<I>Pass</I>)<BR>
</DD>
<DT>Response (one of followings):
<DD>
  HTTP/1.0 200 OK, authorized<BR>
  HTTP/1.0 401 Not authorized<BR>
  HTTP/1.0 403 Forbidden to use the PAM server<BR>
</DD>
</DL>
</KBD>
</UL>

The base of request URL "/-/pam/" can be replaced with an arbitrary path
with PAMCONF="baseurl:/<I>basePath</I>/".
The whole request URL can be replaced by PAMCONF="url:<I>/path</I>".
The content of response message is not cared in the current specification
but it could convey some authentication related data or
capability information in future.
<P>
Following the format, you can easily develop your own PAM server,
instead of PAM-DeleGate, using your own HTTP server with CGI or so.
</UL>
</A>

<A NAME=serv_FTPxHTTP TITLE="FTPxHTTP server">
<P>
<B>FTPxHTTP server</B>
<P>
<UL>
"FTPxHTTP" is a HTTP server which can be used for tunneling the FTP protocol
over HTTP by a (connectionless) sequence of usual HTTP requests
(not by CONNECT but by GET and POST).
It can be relayed by another HTTP proxy for forwarding, filtering or so.
<P>
Example:<UL>
 <KBD>
 hostX% delegated -P8021 SERVER=ftp MOUNT="/* ftpxhttp://hostY:8080/*"<BR>
 hostY% delegated -P8080 SERVER=ftpxhttp MOUNT="/* ftp://hostZ/*"<BR>
 </KBD>
 client --FTP-- ftp://hostX:8021 --HTTP-- http://hostY:8080 --FTP-- ftp://hostZ<BR>
</UL>
</UL>
</A>

<A NAME=serv_YYsh TITLE="YYsh server">
<P>
<B>YYsh server</B>
<P>
<UL>
The yysh server provides remote login and remote command execution
based on the YYSH and YYMUX protocol.
<P>
Example:<UL>
 <KBD>
 hostX% delegated -P6023 SERVER=yysh<BR>
 hostY% delegated -Fyysh hostX:6023<BR>
 </KBD>
</UL>
</UL>
</A>

<A NAME=serv_YYMUX TITLE="YYMUX server">
<P>
<B>YYMUX server</B>
<P>
<UL>
Example:<UL>
 <KBD>
 hostX% delegated -P6010 SERVER=yymux<BR>
 hostY% delegated -P8080 SERVER=http YYMUX=hostX:6010<BR>
 </KBD>
</UL>
</UL>
</A>

<A NAME=SOCKMUX TITLE="multiplexed SOCKS/MASTER/PROXY over SockMux">
<PRE>
SOCKMUX parameter*  ==  SOCKMUX=<I>host</I>:<I>port</I>:<I>option</I>[<I>,option</I>]*
            <I>option</I>  ==  acc | con | ssl
                    --  default: none
                    --  status: <B>tentative</B>
</PRE>
<UL>
If specified together with <A HREF=#SOCKS>SOCKS</A>,
<A HREF=#PROXY>PROXY</A>, <A HREF=#MASTER>MASTER</A> (to chain two DeleGate),
then the communication between DeleGate is multiplexed on a single
persistent connection using <A HREF=#proto_SockMux>SockMux</A>.
This is useful to reduce the delay to establish many connections repeatedly
between DeleGate which are running distant from each other with long RTT.
<P>
<I>host</I>:<I>port</I> specifies the port toward which a SockMux
persistent connection is established.
The connection is established from the DeleGate with "<KBD>con</KBD>"
option to the DeleGate with "<KBD>acc</KBD>" option.
<P>
Options:
<UL>
<KBD>acc -- </KBD>accept a SockMux connection at "<I>host</I>:<I>port</I>".<BR>
<KBD>con -- </KBD>connect a SockMux connection to "<I>host</I>:<I>port</I>".<BR>
<KBD>ssl -- </KBD>use SSL instead of the "Credhy" encryption.
</UL>

<P>
Example: SOCKS proxies chained over SockMux
<UL>
<KBD>hostA% delegated SOCKMUX=hostA:8000:acc SERVER=socks -P2080</KBD><BR>
<KBD>hostB% delegated SOCKMUX=hostA:8000:con SERVER=socks -P1080 SOCKS=hostA:8000</KBD><BR>
</UL>

<P>
Example: SOCKS proxies chained over SockMux connected from the server side
<UL>
<KBD>hostA% delegated SOCKMUX=hostB:8000:<B>con</B> SERVER=socks -P2080</KBD><BR>
<KBD>hostB% delegated SOCKMUX=hostB:8000:<B>acc</B> SERVER=socks -P1080 SOCKS=hostA:8000</KBD><BR>
</UL>

<P>
Example: HTTP proxies chained over SockMux
<UL>
<KBD>hostA% delegated SOCKMUX=hostA:8000:acc SERVER=http -P9080</KBD><BR>
<KBD>hostB% delegated SOCKMUX=hostA:8000:con SERVER=http -P8080 PROXY=hostA:8000</KBD><BR>
</UL>

<P>
Example: HTTP via SOCKS proxy chained over SockMux
<UL>
<KBD>hostA% delegated SOCKMUX=hostA:8000:acc SERVER=socks -P2080</KBD><BR>
<KBD>hostB% delegated SOCKMUX=hostA:8000:con SERVER=http -P8080 SOCKS=hostA:8000</KBD><BR>
</UL>

</UL>
</A>

<A NAME=SOXCONF TITLE="SockMux configuration">
<PRE>
SOXCONF parameter*  ==  SOXCONF=<I>confSpec</I>[,<I>confSpec</I>]*
                    --  default: none
</PRE>
<UL>
<DL>
<DT>crypt:no
<DD>disable the encryption of SockMux packets.
<P>
<DT>packsize:<I>SIZE</I> [16k]
<DD>specify the size of a SockMux packet,
128 in minimum and 16k at the maximum.
</DL>
</UL>
</A>

<A NAME=proto_SockMux TITLE="SockMux protocol">
<A NAME=serv_SockMux TITLE="SockMux server">
<P>
<B>SockMux server</B>
<P>
<UL>
SockMux is an experimental protocol designed for inter-DeleGate communication.
It is a simple protocol for "port forwarding" to accept, relay and destroy
connections, multiplexed over a single persistent connection.
A pair of SockMux-DeleGate establish and retain a connection between them,
then forward port from local to remote each other over the connection.
<P>
The persistent connection is established with "-P<I>host:port</I>" parameter
at receptor side, and "SERVER=sockmux://<I>host:port</I>" at connector side.
The port to accept outgoing connections to be forwarded to remote is specified
with PORT="<I>listOfPorts</I> parameter.
The server to be connected for incoming connections from remote is specified
with a postfix string ",-in" like SERVER="telnet://host:23,-in".
<P>
An incoming connection can be processed with DeleGate as a proxy of the
specified protocol.
If only protocol name is specified like SERVER="telnet,-in", or if "-in"
is postfixed like "-in(<I>option list</I>)", then a DeleGate is
invoked to process the connection.
The <I>option list</I> is passed to the invoked DeleGate as the list of
command line options.
For example, SERVER="telnet://host,-in(+=config.cnf)" will invoke a DeleGate
with command line options like ``delegated SERVER=telnet://host +=config.cnf''.
<P>
Example: bi-directional SockMux-DeleGate<UL>
<KBD>
hostX% delegated SERVER=sockmux -PhostX:9000 PORT=9023 SERVER="telnet://hostX,-in"<BR>
hostY% delegated SERVER=sockmux://hostX:9000 PORT=9023 SERVER="telnet://hostY,-in"<BR>
</KBD>
// a pair of SockMux-DeleGate is connected at the port "hostX:9000", then<BR>
// the port "hostX:9023" is forwarded to "telnet://hostY"<BR>
// the port "hostY:9023" is forwarded to "telnet://hostX"<BR>
</UL>

<P>
Example: uni-directional SockMux-DeleGate<UL>
<KBD>
hostX% delegated SERVER=sockmux -PhostX:9000 SERVER="telnet://hostX,-in"<BR>
hostY% delegated SERVER=sockmux://hostX:9000 PORT=hostY:9023<BR>
</KBD>
// hostY:9023 is forwarded to "telnet://hostX".
</UL>

<P>
Example: uni-directional to proxy-Telent-DeleGate<UL>
<KBD>
hostX% delegated SERVER=sockmux -PhostX:9000 PORT=hostX:9023<BR>
hostY% delegated SERVER=sockmux://hostX:9000 SERVER="telnet,-in"<BR>
</KBD>
// hostX:9023 is forwarded to a Telnet proxy on hostY.
</UL>

<P>
When SockMux is used just to relay data between sockets, without
interpreting the application protocol relayed over SockMux,
such relaying can be represented with simpler expression using
DEST parameter instead of SERVER as follows:
<P>
<UL>
<KBD>DEST</KBD>=<I>host</I>:<I>port</I>[:<I>srcHostList</I>]
for
<KBD>SERVER</KBD>=tcprelay://<I>host</I>:<I>port</I>,-in[:-:<I>srcHostList</I>]
<BR>
<KBD>DEST</KBD>=<I>host</I>:<I>port</I>/udp[:<I>srcHostList</I>]
for
<KBD>SERVER</KBD>=udprelay://<I>host</I>:<I>port</I>,-in[:-:<I>srcHostList</I>]
</UL>
<P>
Example: tcprelay over SockMux<UL>
<KBD>
hostX% delegated SERVER=sockmux://hostY:9000 PORT=hostX:111<BR>
hostY% delegated SERVER=sockmux -PhostY:9000 DEST=hostT:111<BR>
</KBD>
// hostX:111/tcp is forwarded to the server at hostT:111/tcp via hostY.
</UL>

<A NAME=UdpOverTcp>
<P>
Example: relaying UDP over SockMux/TCP<UL>
<KBD>
hostX% delegated SERVER=sockmux://hostY:9000 PORT=hostX:53/udp<BR>
hostY% delegated SERVER=sockmux -PhostY:9000 DEST=hostU:53/udp<BR>
</KBD>
// hostX:53/udp is forwarded to the server at hostU:53/udp via hostY.
</UL>
</A>

<P>
Another way to establish a persistent connection between
two SockMux-DeleGate is using a FIFO device like named pipe.
It is specified like SERVER=sockmux:<I>commtype</I>@<I>fifoName</I>
where <I>commtype</I> is one of "commin", "commout", and "comm",
which represents uni-directional input, uni-directional output and
bi-directional input/output respectively.
<P>
Example: use fifo device on a host<UL>
% mkfifo /tmp/com0<BR>
% mkfifo /tmp/com1<BR>
serv1) SERVER=sockmux:commin@/tmp/com0 SERVER=sockmux:commout@/tmp/com1 ...<BR>
serv2) SERVER=sockmux:commin@/tmp/com1 SERVER=sockmux:commout@/tmp/com0 ...<BR>
</UL>
<P>
Example: use communication port between two hosts (not tested yet)<UL>
host1) SERVER=sockmux:comm@com1 ...<BR>
host2) SERVER=sockmux:comm@com2 ...<BR>
</UL>
<P>
The persistent connection can be established by a given external
program invoked by DeleGate.
The process of the program is passed a socket to/from DeleGate at 
file descriptor number 0 and 1;
<P>
Example: establish connection by external command<UL>
% SERVER="sockmux:proc@<I>connectCommand</I>" ...<BR>
</UL>

<P>
The destination SERVER for an incoming connection from remote can be
selected depending on which port it was accepted.
A SERVER parameter postfixed with
"<A HREF="#SERVER_mount">:-:</A>-P<I>xxxx</I>"
will be applied only to connections which is accepted on remote host
with PORT=<I>xxxx</I>.
<P>
Example: forwarding multiple port<UL>
<KBD>
hostX% ... PORT=8023,8080<BR>
hostY% ... SERVER=telnet,-in:-:-P8023 SERVER=http,-in:-:-P8080<BR>
</KBD>
// hostX:8023 is forwarded to Telnet-proxy on hostY<BR>
// hostX:8080 is forwarded to HTTP-proxy on hostY<BR>
</UL>

<P>
NOTE: forwarding FTP data connection is not supported (yet).
</UL>
</A>
</A>


<A NAME=HTMUX TITLE="SockMux over HTTP">
<PRE>
HTMUX parameter     ==  HTMUX=sv[:[<I>hostList</I>][:<I>portList</I>]]
                     |  HTMUX=cl:<I>host</I>:<I>port</I>
                     |  HTMUX=px:<I>host</I>:<I>port</I>
                    --  restriction: requires <A HREF=#CAPSKEY>CAPSKEY</A>
                    --  default: none
</PRE>
<UL>
HTMUX is used to accept requests at a port which is not directly accessible from
a DeleGate to serve the requests.  Typically it is a port on a remote host.
HTTP DeleGate acts as a HTMUX server when given <KBD>HTMUX=sv</KBD> parameter.
A DeleGate for any application protocol can act as a HTMUX client specifying its
HTMUX server with <KBD>HTMUX=cl:<I>host</I>:<I>port</I></KBD> parameter.
A HTMUX server accepts TCP connections at a port (specified by a HTMUX client)
on the host and relays the connections to HTMUX clients.
<P>
Not only incoming connections but also outgoing connections from a HTMUX client
is established via the HTMUX server by default.
This might not necessary for a DeleGate that relays incoming request to
internal server.  In such case, use the CONNECT parameter to specify such
connections to be established directory, as <KBD>CONNECT="direct:*:192.168.1.*"</KBD>
for example.
<P>
Example:<UL>
<KBD>
hostX% delegated -P192.168.1.1:9876 HTMUX=sv SERVER=http<BR>
hostI% delegated -Pxx.xx.xx.xx:8080 HTMUX=cl:192.168.1.1:9876 SERVER=http<BR>
hostJ% delegated -Pxx.xx.xx.xx:8021 HTMUX=cl:192.168.1.1:9876 SERVER=ftp<BR>
</KBD>
</UL>
<P>
This example implies that <KBD>hostX</KBD> is a multi-homed host with
a private addresses 192.168.1.1 and a global address xx.xx.xx.xx.
The DeleGate on <KBD>hostX</KBD> acts as a HTMUX server.
HTTP DeleGate on <KBD>hostI</KBD> and FTP DeleGate on <KBD>hostJ</KBD> act as
HTMUX client which remotely accepts requests (arrived at xx.xx.xx.xx) via
the HTMUX server on <KBD>HostX</KBD>.
<P>
A pair of HTMUX server and client uses a single persistent connection to relay
multiple parallel connections on it multiplexing them by the
<A HREF=#proto_SockMux>SockMux</A> protocol.<BR>
This feature must not be exploited maliciously, for example to invite
incoming connections violating a restriction on a firewall.
Therefore you need to install <A HREF=#CAPSKEY>CAPSKEY</A> to enable this feature.
Other usages of HTMUX being disabled by default are 
non-direct connection between client and server (connection via NAT or proxy),
too large clock skew between client and server (300 seconds by default),
or inserting SSL encryption between client and server.
<P>
There are two ways to enable non-direct connection for HTMUX.
One way is to install a CAPSKEY to enable indirect HTMUX connection.
Another way is inserting a HTMUX proxy as the following example.
<P>
Example: cascading HTMUX with a HTMUX proxy<UL>
<KBD>
hostX% delegated -PhostX:9876 HTMUX=sv SERVER=http<BR>
hostI% delegated -PhostI:6789 HTMUX=px:hostX:9876 SERVER=http<BR>
hostJ% delegated -PhostX:8080 HTMUX=cl:hostI:6789 SERVER=http<BR>
</KBD>
</UL>
<P>
The persistent connection between HTMUX client and server is capable to
convey connections bi-directionally,
thus can be used to make a pair of proxies over it.
Each proxy accepts requests at the local port and forwards them to the
remote peer as the following example.
<P>
Example: using HTMUX to make symmetric proxies (the simplest generic configuration)<UL><KBD>
hostX% delegated -P9876 HTMUX=sv SERVER=http<BR>
hostY% delegated -P8080 HTMUX=cl:hostX:9876 SERVER=http
</KBD></UL>
<P>
In this example, -P8080 is equivalent to a wild-card address expression
"-P*:8080" to accept from the port number 8080 on any network interfaces
on the host.
Therefore requests to the port 8080 on any interface on hostX is forwarded
to the servers via the DeleGate on hostY as a HTMUX client (and a HTTP proxy).
Symmetrically, requests to the port 8080 on any interface on hostY is
forwarded to the servers via the DeleGate on hostX as a HTTP proxy (and a
HTMUX server at hostX:9876).
<BR>
(Again, note that this feature is disabled by default and needs
<A HREF=#CAPSKEY>CAPSKEY</A> to enable it)
<P>
The port to be used on the server side and on the client side can be specified
separately with the "/local" and "/remote" modifiers for
<A HREF=#opt_P>-P</A> or <A HREF=#opt_Q>-Q</A> option.
"/local" marks a port to be used on the local host (on a HTMUX client),
and "/remote" marks the port to be used on the remote host (on a HTMUX server).
The specification "-P8080" in the above example is equivalent to
"-P*:8080/remote,*:8080/local".
<P>
Example: using HTMUX bi-directionally<UL><KBD>
hostX% delegated -PhostX:9876 HTMUX=sv SERVER=http<BR>
hostI% delegated -Plocalhost:8081 HTMUX=cl:hostX:9876 SERVER=http<BR>
hostJ% delegated -P8082/remote,8083/local HTMUX=cl:hostX:9876 SERVER=http
</KBD></UL>
<P>
In this example, between <KBD>hostX</KBD> and <KBD>hostI</KBD>,
requests to <KBD>localhost:8081</KBD> on each host are forwarded to the peer
(equivalent to "<KBD>-Plocalhost:8081/remote,localhost:8081/local</KBD>")
Between <KBD>hostX</KBD> and <KBD>hostJ</KBD>,
<KBD>hostX:8082</KBD> and <KBD>hostJ:8083</KBD> are forwarded to the peer
(equivalent to "<KBD>-PhostX:8082/remote,hostJ:8083/local</KBD>")
<P>
Example: using HTMUX only for outbound requests<UL><KBD>
hostX% delegated -PhostX:9876 HTMUX=sv SERVER=http<BR>
hostI% delegated -Plocalhost:8084/local HTMUX=cl:hostX:9876 SERVER=http
</KBD></UL>
<P>
This is an example to use HTMUX only for outbound requests.
It works even without the HTMUX parameter, but with HTMUX, a single
persistent connection is used between the server and client.
This usage of HTMUX is enabled by default when DeleGate is executed
in foreground (with <A HREF=#opt_f>-fv</A> option,
running not as a service or a daemon),
without restrictions described as above, and don't require CAPSKEY.
</UL>
</A>

<A NAME=CAPSKEY TITLE="Encrypted Capability List">
<PRE>
CAPSKEY parameter*  ==  CAPSKEY=<I>opaque</I>
                    --  default: none
</PRE>
<UL>
Some functionalities of DeleGate are disabled by default and need
CAPSKEY to be enabled.
You can get automatically issued CAPSKEY for evaluation use via mail.
Run DeleGate as "<KBD>delegated -Fcapsreq ADMIN=<I>Email-address</I></KBD>"
and follow the instruction shown in the output.
</UL>
</A>


<A NAME=serv_Socks TITLE="Socks server">
<P>
<B>Socks server</B>
<P>
<UL>
Socks-DeleGate with SERVER=socks accepts both SocksV4 and SocksV5,
whereas SERVER=socks4 and SERVER=socks5 accepts only SocksV4 and SocksV5
respectively.
Currently, only USER/PASS authentication scheme of SocksV5 is supported.
<P>
Example: Socks-DeleGate<UL>
<KBD>
# delegated -P1080 SERVER=socks</UL>
</KBD>
Example: forwarding to an upstream Socks server
<UL>
<KBD>
# delegated -P1080 SERVER=socks SOCKS=<I>sockhost</I></UL>
</KBD>
<P>
To accept an incoming TCP connection via a SOCKS-DeleGate server,
the network interface to be used for it is selected automatically
by DeleGate (based on the DST.ADDR or DSTIP which is sent from
a SOCKS client as the parameter of the BIND command).
With the <A HREF=#SRCIF>SRCIF</A> parameter, you can select a network
interface (and port number) manually, with the pseudo protocol name "tcpbind".
The complete syntax of the parameter is
SRCIF=
"[<I>host</I>]:[<I>port</I>]:tcpbind[:<I>dstHostList</I>[:<I>srcHostList</I>]]".
Typically, only the <I>host</I> filed is specified to select a network
interface, like SRCIF="150.29.202.120::tcpbind" for example.

<P>
<B>NOTE</B>: When you chain DeleGate with another SOCKS server, it may
cause problems in UDP relaying due to the private and tentative
extensions to the SOCKS protocol by DeleGate.
The following SRCIF parameters can be useful to escape such problems.
<UL>
<LI><KBD>SRCIF="<I>host</I>:<I>port</I>:socks-udp-tosv"</KBD>
 -- network interface to servers<BR>
<KBD>SRCIF="0.0.0.0:0:socks-udp-tosv"</KBD>
makes DeleGate as a SOCKS client behave compliantly to
the SOCKSv5 specification on UDP ASSOCIATE.
<BR>
<LI><KBD>SRCIF="<I>host</I>:<I>port</I>:socks-udp-tocl"</KBD>
 -- network interface to clients<BR>
<KBD>SRCIF="0.0.0.0:0:socks-udp-tocl"</KBD>
suppresses the failure in DeleGate as a SOCKS server
trying to bind a UDP socket to a specific port number.
</UL>

</UL>
</A>
</A>

<A NAME=SOCKSTAP TITLE="SOCKSTAP parameter">
<PRE>
SOCKSTAP parameter*  ==  SOCKSTAP=<I>ProtoList</I>[:[<I>dstHostList</I>][:[<I>srcHostList</I>][:<I>params</I>]]]
                     --  default: none
</PRE>
<UL>
If specified with a SOCKS server, the data stream relayed over the SOCKS is
interpreted in each application protocol.
For example, with <KBD>SOCKSTAP=http</KBD>, the delegated act as a server
of SERVER=http when the relayed protocol is detected to be the HTTP protocol.
<P>
Example: Socks-DeleGate which do caching for HTTP and FTP<UL>
<KBD>
% delegated -P1080 SERVER=socks CACHE=do SOCKSTAP=http,ftp
</KBD>
</UL>
<P>
Example: Socks-DeleGate which do caching for HTTP with an upstream proxy<UL>
<KBD>
% delegated -P1080 SERVER=socks SOCKSTAP="http:::CACHE=do PROXY=pxserv:8080"
</KBD>
</UL>
<P>
See
<A HREF=http://www.delegate.org/delegate/sockstap/>http://www.delegate.org/delegate/sockstap/></A>
for more details.
</UL>
</A>


<A NAME=serv_HTTP TITLE="HTTP proxy/server">
<P>
<B>HTTP proxy/server</B>
<P>
<UL>
Example: DeleGate as an HTTP proxy<UL>
<KBD>
<I>firewall</I>% delegated -P8080 SERVER=http
</KBD>
<P>
Then use this DeleGate from your client on the internal host,
specifying "<I>firewall</I>:8080" as the proxy for
HTTP, HTTPS (Security), FTP, Gopher, Wais, and so on.
</UL>

<P>
Example: cascaded DeleGate as an HTTP proxy<UL>
<KBD>
<I>firewall</I>% delegated -P8888 SERVER=delegate RELIABLE=<I>internal</I><BR>
<I>internal</I>% delegated -P8080 SERVER=http MASTER=<I>firewall</I>:8888
</KBD>
<BR>
<P>
Run a generalist DeleGate on the <I>firewall</I> which only accepts
request from <I>internal</I> host,
then run a specialist on <I>internal</I> which use the generalist
on <I>firewall</I> host.
A generalist can be shared as an upstream DeleGate from multiple
DeleGates of arbitrary protocol.
</UL>

<P>
Example: DeleGate as an origin HTTP server<UL>
<KBD>
<DL>
<DT>host# delegated -P80 SERVER=http \
<DD>MOUNT="/* /path/of/www/*" RELAY=no RELIABLE="*"
</DL>
</KBD>
<P>
A file with a name with ".cgi" extension is treated as a CGI script.
Also you can use arbitrary name of CGI scripts under a specified
directory with a MOUNT like:<BR>
<KBD>
MOUNT="/xxx/* cgi:/path/of/cgi-bin/*"
</KBD>
</UL>

<A NAME=Fcgi TITLE="DeleGate as a CGI program">
<P>
Example: DeleGate as a CGI program<UL>
You can use DeleGate as a CGI program from a HTTP server. For example,
specify in the "httpd.conf" file of your HTTP server(A) as follows.
<UL>
Exec /other/*  /path/of/cgi-delegate
</UL>
Then write the content of the file /path/of/cgi-delegate as follows:
<UL>
<KBD>
#!/bin/sh<BR>
<DL>
<DT>delegated -Fcgi
<DD>MOUNT="/-* =" \<BR>
MOUNT="/www2/* http://wwwserv2/*" \<BR>
MOUNT="/news/* nntp://newsserv/*"<BR>
</DL>
</KBD>
</UL>
This will add a pseudo sub tree "/other/" onto server(A)
including 
/other/www2/ which is a content of a HTTP server "wwwserv2", and
/other/news/ which is a content of a NNTP server "newsserv".
</UL>
</UL>
</A>

<A NAME=httplog TITLE="HTTP Transfer Log Format">
<P>
HTTP Transfer Log Format<BR>
<UL>
The format of PROTOLOG for HTTP protocol can be modified with a
optional format specification postfixed after the <I>LogFilename</I> as
PROTOLOG="<I>LogFilename</I>:<I>format</I>".
In this case, default file name can be omitted.
For example, <KBD>PROTOLOG=":%X"</KBD> specifies making a NCSA like
extended common logfile format.
The default format is
<KBD>PROTOLOG=":%C %D"</KBD> in version 9.

<P>
<UL>
<TABLE BORDER=0 CELLSPACING=0>
<TR><TD><KBD>%C</KBD><TD> -- common logfile format of CERN-HTTPD
<TR><TD><KBD>%c</KBD><TD> -- same as %C except the date is recorded in millisecond precision
<TR><TD><KBD>%D</KBD><TD> -- extension by DeleGate
 (<KBD><I>connTime</I>+<I>relayTime</I>:<I>status</I></KBD>)
<TR><TD><KBD>%X</KBD><TD> == <KBD>'%C "%r" "%u"'</KBD> common logfile format with Referer and User-Agent
<TR><TD><KBD>%r</KBD><TD> -- Referer field in the request message
<TR><TD><KBD>%u</KBD><TD> -- User-Agent field in the request message
<TR><TD><KBD>%S</KBD><TD> -- status of CONNECTion to the server (c,m,p,d,s,v)
<TR><TD><KBD>%s</KBD><TD> -- session Id by HTTPCONF=<A HREF=#http_session>session</A>
<TR><TD><KBD>%As</KBD><TD> -- session Id in Digest Authorization 
<TR><TD><KBD>%{<I>field</I>}<TD> -- arbitrary field in the request message
</TABLE>
</UL>
</P>
The client information part in %C, which records hostname, Ident,
and username by default, can be modified by AUTH="log:" parameter.

<P>
<A NAME=http_session_log>
The session identifier put by "%s" is generated by specifying
HTTPCONF=<A HREF=#http_session>session:cookie</A> option while
"%As" is generated by AUTHORIZER=<A HREF=#dgauth>-dgauth</A> option.
The format of session identifier is as this:
<UL>
<I>time</I>.<I>pid</I>.<I>proc#</I>+<I>conn#</I>[+<I>req#</I>].<I>reqnum</I>
</UL>
<P>
For example, "031114-173045.1234.5+6+7.9" means that
it is the 9th request from the client
in the session started at 17:30:45 on November 14 by the process of PID=1234.
The start of the session is recorded in LOGFILE as this:
<UL>
11/14 17:30:45 [1234] 5+6/7: NewSession 031114-173045.1234.5+6+7.0
</UL>
<P>
Note that the <I>reqnum</I> part may not be unique because of parallel or
pipelined requests generated by a client as the owner of the session.
Note that the <I>reqnum</I> part for "%As" may not be incremented on each
request because the container of session identifier,
the opaque" parameter in Digest Authentication in this case,
may not be updated on each request.
</A>

</UL>
</A>

<A NAME=HTTPCONF TITLE="HTTPCONF parameter">
<PRE>
HTTPCONF parameter  ==  HTTPCONF=<I>what</I>:<I>conf</I>
</PRE>
<UL>
<DL>
<DT>welcome:listOfWelcomeFiles
<DD>
-- default: welcome.{<A HREF="#dgp">dgp</A>,<A HREF="#SSI.shtml">shtml</A>,html,cgi},index.{dgp,shtml,html,cgi},-dir.html
<BR>
A list of index files or CGI scripts which should be used for URLs
of directories ending with "/" like "/path/".  This is a list of
candidate file names.  The list may be ended with "-dir.html" which
means a built-in index generator.  If the list is empty, empty data
is substituted for index data.

<P>
<DT>search:pathOfSearchScript
<DD>
-- default: none<BR>
The path of a CGI script to be applied for URLs with search part like
"/path?search".  This is a global specification applied for all URLs.
Also you can specify a local search script for each MOUNT point like
<UL>
<KBD>
MOUNT="/path2/* /root/of/path2/* search:script2".
</KBD>
</UL>
This local specification is prior to the global one.  A special local
specification "search:-" can be used just to ignore the global
specification for the MOUNT point.
</DD>

<P>
<A NAME=nvserv_auto TITLE="HTTPCONF=nvserv parameter">
<DT>nvserv:noauto | auto | alias | gen | none
<DD>
-- default: HTTPCONF=nvserv:noauto<BR>
Automatically detects virtual servers in MOUNT parameters and notate
each of them as a MOUNT rule to be applied only to a virtual server.
It can be done manually by specifying "<A HREF=#nvserv>nvserv</A>" MountOption
for each MOUNT parameter.
"nvserv:alias" means detecting target servers of host names with
common IP-addresses and notate them as virtual servers.
"nvserv:gen" means notating MOUNT parameters with "genvhost"
MountOption as virtual servers.
"nvserv:auto" is equivalent to "nvserv:alias,gen".
The guessing can be overridden by explicitly specifying
the <A HREF=#nvserv>avserv</A> MountOption for each MOUNT parameter.
"nvserv:none" disables any treatment of virtual servers which are
detected automatically or specified explicitly by the "nvserv" MountOption.
</DD>
</A>

<P>
<DT>methods:<I>listOfAcceptableMethods</I>
<DD>
-- default: methods:OPTIONS,GET,HEAD,POST,PUT,...<BR>
-- See the output to LOGFILE with HTTPCONF=methods:"+"<BR>
Limit or add HTTP methods to be accepted.<BR>
<P>
Example:
<UL>
<KBD>
HTTPCONF=methods:GET,HEAD     -- accept only GET and HEAD<BR>
HTTPCONF=methods:-POST,-PUT   -- don't accept POST and PUT<BR>
HTTPCONF=methods:+,NEWMETHOD1 -- add NEWMETHOD1 to be accepted<BR>
HTTPCONF=methods:*            -- accept any methods<BR>
</KBD>
</UL>

<P>
<DT>rvers:<I>listOfAcceptableResponseVersions</I>
<DD>
-- default: rvers:HTTP<BR>
Add versions in response message from HTTP servers.
<P>
Example:
<UL>
<KBD>
HTTPCONF=rvers:+,ICY<BR>
HTTPCONF=rvers:* -- accept any response version
</KBD>
</UL>
</DD>

<A NAME=post-ccx-type>
<P>
<DT>post-ccx-type:<I>listOfTypes</I>
<DD>
-- default: post-ccx-type:x-www-form-urlencoded<BR>
Specify the list of names of Content-Type of request message to which
conversion by <A HREF=#CHARCODE>CHARCODE</A> is applied.
<P>
Example:
<UL><KBD>
HTTPCONF=post-ccx-type:+,multipart/form-data
</KBD></UL>
</DD>
</A>

<A NAME=cryptCookie TITLE="cookie encryption and filtering">
<P>
<DT>cryptCookie:<I>listOfCookies</I>:<I>cryptKey</I><BR>
<DD>
<I>listOfCookies</I> == <I>attributes</I>[@<I>domains</I>]<BR>
<I>attributes</I> == <I>attribute</I> | {<I>attribute</I>,<I>attribute</I>,...}<BR>
<I>domains</I> == <I>domain</I> | {<I>domain</I>,<I>domain</I>,...}<BR>
<I>domain</I> == [.]<I>domainName</I><BR>
<I>cryptKey</I> == <I>string</I> | <A HREF=#authgen><KBD>%a</KBD> | <KBD>%P</KBD></A>
<P>
encrypt specified attributes in a Set-Cookie response to be stored in a client,
then decrypt and forward the Cookie request only to the originator
of the Cookie.
An attribute in a Cookie is specified as "<I>attribute</I>@<I>host</I>"
or "<I>attribute</I>@.<I>domain</I>".
In the former case, a cookie generated by a <I>host</I> is encrypted
and echoed to <I>host</I> only.
In the latter case, a cookie generated by hosts in the <I>domain</I>
can be echoed to hosts in the <I>domain</I>.
The special string "<KBD>%a</KBD>" in <I>cryptKey</I> is substituted by
the IP-address of the client.  This makes the crypted Cookie be usable
only by clients on the host of the IP-address.
<P>
Example:<UL><KBD>
HTTPCONF="cryptCookie:SessionID@host1.dom1,UserID@.dom2:nanjamonja"<BR>
HTTPCONF="cryptCookie:UserID@.dom:nanjamonja"<BR>
HTTPCONF="cryptCookie:UserID@{host1.dom,host2.dom}:nanjamonja"<BR>
</KBD></UL>
</DD>
</A>


<A NAME=http_edithead TITLE="HTTP header rewriting">
<A NAME=httpconf_killhead TITLE="header filtering">
<P>
<DT>kill-[i][qr]head: <I>listOfHeaders</I>
<DD>erase header fields listed in <I>listOfHeaders</I> before forwarding
a request/response message to server/client. "kill-qhead" is applied
only to request message to server and "kill-rhead" is applied only to
response message to client.
If "i" is prefixed as "kill-iqhead:Pragma,Cache-Control", the specified
fields are erased before DeleGate interpret it as the HTTP headers.
<P>
Example:<UL><KBD>
HTTPCONF=kill-qhead:Referer<BR>
HTTPCONF=kill-qhead:If-*,Accept-*<BR>
HTTPCONF=kill-rhead:Set-Cookie<BR>
</KBD></UL>
</DD>
</A>
<P>

<A NAME=httpconf_addhead TITLE="header generation">
<P>
<DT>add-[i][qr]head:<I>name</I>:<I>body</I>
<DD>add a header <I>name</I>:<I>body</I> to forwarded request/response message.
Client's identity information can be inserted into <I>body</I> string
with "%<A HREF=#authgen>format</A>" notation. 
If "i" is prefixed as "add-ihead:Pragma:no-cache", then the specified field
with the body is added to the input to be interpreted by DeleGate
as a HTTP header from the client or the server.
<P>
Example:<UL><KBD>
HTTPCONF="add-qhead:X-Forward-For:%a"<BR>
</KBD></UL>
</DD>
</A>
<P>
</A>

<A NAME=httpconf_replacehead TITLE="header replacement">
<P>
<DT>replace-[i][qr]head:<I>name</I>:<I>body</I>
<DD>replace headers of "<I>name:</I>" with "<I>name</I>:<I>body</I>"
in forwarded request/response message.
This is equivalent to the combination of
<KBD>kill-head</KBD> and <KBD>add-head</KBD>.
</DD>
<P>
Example:<UL><KBD>
HTTPCONF=replace-qhead:Referer:http://x.y.z<BR>
<NOBR>HTTPCONF=kill-qhead:Referer HTTPCONF=add-qhead:Referer:http://x.y.z
</NOBR>
</KBD></UL>
</A>
<P>

<DT>kill-tag: <I>listOfTags</I>
<DD>disable a tag listed in <I>listOfTags</I> when it it used in
a text/html response from a server.
<P>
Example:<UL><KBD>
HTTPCONF=kill-tag:SCRIPT,APPLET<BR>
</KBD></UL>

<P>
<DT>ver:1.0
<DD>act as a HTTP/1.0 client/server
<DT>svver:1.0
<DD>act as a HTTP/1.0 client against servers (send request in HTTP/1.0)
<DT>clver:1.0
<DD>act as a HTTP/1.0 server against clients
    (do not use chunked encoding in response)
<DT>acc-encoding:<I>encoding</I> [-thrugzip]
<DD>Accept-Encoding header to be sent to server.
This is applied to DeleGate which does some interpretation of content
with MOUNT, CHARCODE, CACHE, etc.  To do such interpretation, the content
(response body) is not to be encoded in a format unknown to DeleGate.
"identity" specifies disabling any encoding of content in the server.
"-thrugzip" specifies forwarding Accept-Encoding:gzip from client to server.
If the program "gzip" is not available on the host of DeleGate
(i.e. not found in <A HREF=#LIBPATH>LIBPATH</A>),
"identity" is sent regardlessly.

<DT>gen-encoding:<I>encoding</I> [gzip]
<DD>The encoding applied to the content sent from DeleGate to client.
Only "gzip" is available in the current implementations.
"identity" and others disable any encoding.

<P>
<DT>tout-wait-reqbody:<A HREF="#period-value"><I>period</I></A> [30]
<DD>max. period to wait the first data in request body.
<DT>tout-in-reqbody:<A HREF="#period-value"><I>period</I></A> [15]
<DD>max. period to wait next data in request body.
 (adjustable for a slow filter program at the client side)
<DT>tout-buff-reqbody:<A HREF="#period-value"><I>period</I></A> [5]
<DD>max. period to do buffering request message to server
<DT>tout-buff-resbody:<A HREF="#period-value"><I>period</I></A> [8]
<DD>max. period to do buffering response message to client
</DD>

<A NAME=tout-cka>
<DT>tout-cka:<A HREF="#period-value"><I>period</I></A> [5]
<DD>max. period to keep a connection with the client alive.
(the timeout is ten times longer for the first connection from each client host)
</DD>
</A>
<A NAME=max-cka>
<DT>max-cka:<I>number</I> [50]
<DD>max. number of requests to be relayed on a single connection
 in keep-alive.
(ten times larger value is given to the first connection from each client host)
<BR>
This is applied to the communication over a connection of SSLtunnel by the
CONNECT method too.  A pair of upstream and downstream data is
regarded as a pair of request and response on HTTP, then the maximum
number of such pairs is restricted.
</DD>
</A>
<A NAME=max-ckapch>
<DT>max-ckapch:<I>number</I> [8]
</A>
<DD>max. number of connections in keep-alive at a time for each client host.
<DT>max-reqline:<I>length</I> [8k]
<DD>max. length of request line to be accepted.
<DT>max-reqhead:<I>length</I> [12k]
<DD>max. length of request header to be accepted.
<DT>max-gw-reqline:<I>length</I> [512]
<DD>max. length of request line to be forwarded to another server
  in another protocol.
<DT>max-hops:<I>number</I> [20]
<DD>max. number of hops in the chain of HTTP proxies.
<DT>tout-resp:<A HREF="#period-value"><I>period</I></A>
[TIMEOUT=<A HREF="#TIMEOUT-io">io</A>]
<DD>max. period to wait response from server.

<DT>tout-pack-intvl</DT> [10.0]
<DD>max. interval between packets relayed on <A HREF=#SSLtunnel>SSLtunnel</A>
by the CONNECT method.

<DT>halfdup
<DD>Forbid full-duplex usage of SSLtunnel by the CONNECT method.

<DT>urlesc[:<I>escChars</I>] [<I>empty</I>]
<DD>the set of characters in request URL to be escaped by "%<I>XX</I>"
notation before any processing.
As a special case, HTTPCONF="urlesc" means HTTPCONF="urlesc:&lt;&gt;".


<A NAME="proxycontrol">
<DT>proxycontrol[:{on|off}]
<DD>
consume substring following "?_?" in request URL as control information for
the DeleGate; when DeleGate get request <I>URL</I>?_?<I>proxycontrol</I>,
only <I>URL</I> part is forwarded to the server
and <I>proxycontrol</I> part is (possibly) used by DeleGate.
</DD>
</A>

<DT>cka-cfi
<DD>make connection with the client keep-alive even with external filter
(FCL, FTOCL).
</DD>

<A NAME=HTTPCONF_nolog>
<DT>nolog:<I>listOfCodeType</I>[:<A HREF=#connMap>connMap</A>]
<DD>
<I>listOfCodeType</I> == [ <I>respCode</I> / ][ <I>Type</I> [ / <I>subType</I> ] ]
<BR>
specify response code or Content-Type of response message
not to be logged in access log (<A HREF=#PROTOLOG>PROTOLOG</A>).
<P>
Example:<UL><KBD>
HTTPCONF="nolog:302,304,image"<BR>
</KBD></UL>
</DD>
</A>

<DT>xferlog:ftp
<DD>record FTP/HTTP transactions in <A HREF="#xferlog">xferlog</A> format too.

<DT>bugs:<I>listOfBugs</I>
<DD><I>listOfBugs</I> is a list of features to be disabled
to bypass possible bugs as follows:
<UL>
<DL>
<DT>no-gzip ... disable Content-Encoding:gzip
<DT>no-keepalive ... disable Connection:Keep-Alive
<DT>no-keepaliveproxy ... disable Connection:Keep-Alive with client side proxy
<DT>no-chunked ... disable Transfer-Encoding:chunked
<DT>no-flush-chunk ... disable flushing response after each chunk
<DT>kill-contleng ... erase original Content-Length in chunked encoding
<DT>add-contleng ... add or update Content-Length even in chunked encoding
<DT>do-authconv ... enable Authentication conversion from client's Basic to server's Digest
</DL>
</UL>

<DT>bugs:thru-304
<DD>
disable the conversion from "304 Not Modified" to "200 Ok" in the message
as the response to a conditional request with the "If-Modified-Since" header.
DeleGate with external filters tries to return a HTTP response messages with
a body (with the code "200 Ok") when it is filtered (and possibly rewritten)
by the filters even if the body should be returned as empty (304 Not Modified)
based on the modification date (Last-Modified) of the target data.
This is necessary to return data rewritten dynamically by filters, but it
disables the merit by the conditional request and the "304" response.
"thru-304" turns the above conversion off and let DeleGate pass through
"If-Modified-Since" request from clients and the "Last-Modified" and
"304 Not Modified" response from servers.

<DT>svauth:no-basic
<DD>
Stop forwarding Basic Authorization (which contains cleartext password)
from client to server.
If the server supports Digest authentication, then the DeleGate do it
by proxy of the client.

<DT>svauth:less-basic
<DD>
Postpone forwarding Basic Authorization from client to server until
the server requires the Basic Authentication.
</DD>

<A NAME=http_session>
<DT>session:cookie
<DD>
Enable session management based on Cookie.
The <A HREF=#http_session_log>session identifier</A>
is passed to CFI/CGI programs in
environment variable "X_COOKIE_SESSION", and
can be logged into <A HREF=#http_session_log>PROTOLOG</A>.
<P>
Example:
<UL><KBD>
HTTPCONF=session <A HREF=#http_session_log>PROTOLOG</A>=":%s %X"
</KBD></UL>
</DD>
</A>

<P>
<DT>Example:
<DD>
<KBD>
HTTPCONF=search:/path/of/searchScript<BR>
MOUNT="/bin/* cgi:/path/of/cgi-bin/* search:-"<BR>
MOUNT="/*     file:/path/of/data/*"<BR>
</KBD>

</DL>
</UL>
</A>


<A NAME=FILETYPE TITLE="">
<PRE>
FILETYPE parameter  ==  FILETYPE=<I>suffix</I>:<I>gopherType</I>:<I>altText</I>:<I>iconName</I>:<I>contentType</I>
                    --  default: FILETYPE=".txt:0:TXT:text:text/plain"
                                 FILETYPE=...
</PRE>
<UL>
Define file name to content-type mapping.
<P>
<DL>
<DT><I>gopherType</I>:
<DD>
0 - text,
1 - directory,
4 - BinHex,
6 - uuencode,
9 - binary,
g - gif,
I - image,
...

<DT><I>altText</I>:
<DD>alternative text which should be displayed for the icon image
in text only displays
(embedded into IMG tag in HTML text like &lt;IMG ALT="<I>altText</I>" ... &gt;)

<DT><I>iconName</I>:
<DD>one of binary, binhex, compressed, directory, document, ftp, gzip,
image, index, index2, movie, sound, tar, telnet, text, unknown, uu
(see http://<I>delegate</I>/-/builtin/icons/)

<DT><I>contentType</I>:
<DD>text/plain,
image/gif,
...
(see <A HREF="ftp://ftp.ietf.org/rfc/rfc2045.txt">RFC2045</A>)
</DL>
<P>
Example:
<KBD>
<UL>
FILETYPE=".txt:0:TXT:text:text/plain"<BR>
FILETYPE=".gif:g:GIF:image:image/gif"
</UL>
</KBD>
</UL>
</A>


<A NAME=CGIENV TITLE="">
<PRE>
CGIENV parameter    ==  CGIENV=<I>name</I>[,<I>name</I>]*
                    --  default: CGIENV="*"
</PRE>
<UL>
A list of environment variables to be passed to CGI program.
</UL>
</A>


<A NAME=HTTP_mount TITLE="MountOptions for HTTP-DeleGate">
<PRE>
MountOptions for HTTP-DeleGate
</PRE>
<UL>
CONDITIONS:
<DL>
<DT>vhost={<I>HostList</I>} -- virtual host matching and rewriting.
<DD>
true if the value of the "Host:" field in the request message is included
in the <I>HostList</I> for request rewriting, and true unconditionally
for response rewriting.
It supports  <I>virtual hosting</I> by a special rewriting for response,
that is, any full-URL of a real host in a response message will be
rewritten to that of a virtual host.

<DT>avhost={<I>HostList</I>} -- address based virtual hosting
<DD>
equivalent to the "vhost" option.

<DT>nvhost={<I>HostList</I>} -- name based virtual hosting
<DD>
similarly to "vhost" option, "nvhost" is used to configure virtual hosting
except that this option is restricted to create name based virtual hosts
which are distinguished each other only by their host names.
Each virtual host is identified textually by its name (thus no "-" prefix
for each host is necessary to force textual-only matching which is necessary
with the "vhost" option).
For example, the following two MOUNT parameters are equivalent to each other.
<BR>
<KBD>&nbsp;MOUNT="/* http://server/* vhost=-www.domain"</KBD><BR>
<KBD>&nbsp;MOUNT="/* http://server/* nvhost=www.domain"</KBD>
<BR>
A special option <KBD>"nvhost=-thru"</KBD> can be used
to ease forwarding a virtual domain name indicated by a client to a server.
The option means matching with virtual domain name to be sent to the target
server.
By default, the domain name can be specified explicitly with the
<A HREF=#nvserv>nvserv</A> or the target server name in the <I>rURL</I>
of this MOUNT rule by default.
For example, the following three MOUNT parameters are equivalent mutually.
<BR>
<KBD>&nbsp;MOUNT="/* http://domain/* nvhost=-thru,rserv=server"</KBD>
<BR>
<KBD>&nbsp;MOUNT="/* http://server/* nvhost=-thru,nvserv=domain"</KBD>
<BR>
<KBD>&nbsp;MOUNT="/* http://server/* nvhost=domain,nvserv=-thru"</KBD>
<BR>

<DT>qmatch=<I>pattern</I> -- pattern matching in the request header
<DD>
true if the <I>pattern</I> matches with string in the request header.
(ex. qmatch=*User-Agent:*compatible;%20MS*)

<DT>dstproto={<I>ProtoList</I>} -- to the server of specified protocol
<DD>
true if the protocol of the destination server is in the <I>ProtoList</I>.

<DT>method={<I>methodList</I>} -- request method
<DD>
true if the access method of the current request is included in the
<I>methodList</I>.

<DT>asproxy
<DD>true if the DeleGate is called as a proxy server that is
the requested URL is in full URL format.

<DT>!asproxy
<DD>true if the DeleGate is not accessed as a proxy server in the request.

<DT>withquery
<DD>true if the requested URL has "?<I>query</I>" component
</DL>

<P>
CONTROLS:
<DL>
<DT>authorizer=<I>authServList</I>
<DD>
the <A HREF=#AUTHORIZER>AUTHORIZER</A> which is to be applied to this MOUNT point.
If AUTHORIZER is specified in both MountOption and command line option,
the one in MountOption is used.

<DT>moved[={300|301|302|303}]
<DD>don't relay to <A HREF="#MOUNT"><I>rURL</I></A> but return response for redirection
as "302 Moved" with "Location:<I>rURL</I>".
Redirection within the same server can be eased using the
<A HREF=#MountAbbrev>abbreviation</A> of host-name in the <I>rURL</I>
like MOUNT="/path1 ///path2 moved".

<DT>referer</DT>
<DD>
Apply the rewriting only to the Referer: field to be forwarded.
This is an synonym of "where=ref".

<DT>useproxy[=<I>proxyURI</I>]
<DD>generate "305 Use Proxy" response message.
If proxyURI is omitted or given as "direct", the response
message is sent with Set-Proxy field as "Set-Proxy: DIRECT".
Otherwise the URI is set in the field as
"Set-Proxy: SET; proxyURI=proxyURI".

<DT>realm=<I>realmString</I>
<DD>specify the realm of authentication.

<DT>forbidden
<DD>reject the request as forbidden (synonym of "rcode=403")

<DT>unknown
<DD>reject the request as unknown (synonym of "rcode=404")

<DT>rcode={300|301|302|303|304|305|306|403|404}
<DD>return the response with the specified status code,
which can be useful for customizing error messages.
</DD>

<A NAME=onerror>
<DT>onerror[=<I>listOfCodes</I>]
<DD>this MOUNT entry is used to substitute a response message when an
error occurred.
It is applied If the response status code for the request shows an error (4xx
or 5xx), and the status code is in the <I>listOfCodes</I> if it is specified.
For example with MOUNT="/path/* file:/tmp/autherr.cgi onerror={401,407}",
the output from /tmp/autherr.cgi is sent when authentication error occurred
in access to URLs under "/path/".
</DD>
</A>

<DT>robots={no|ok}
<DD>allow or disallow retrievals from robots.
The default value for NNTP and FTP is "no", while it is
"ok" for other protocols.
</DD>

<A NAME=nvserv TITLE="nvserv=host MountOption">
<DT>nvserv | nvserv=<I>host</I>  -- forwarding to a name based virtual server
<DD>specify MOUNTing the target server as a name based virtual hosting server.
The virtual host name to be sent to the server can be specified as
"nvserv=<I>host</I>" or it is the host name part in the <I>rURL</I> by default.
With this option, the target server is MOUNTed only as a virtual server of
the <I>host</I> name while other servers, of alias names of the <I>host</I>
or IP-addresses of the <I>host</I>, are not MOUNTed.
This means that the MOUNT rule will be applied for rewriting of URL in a
HTTP response message only if the hostname of a URL matches textually with
the virtual host name of the target server.
The virtual hostname from the client can be passed through to the server
with "nvserv=-thru".

<DT>avserv | avserv=<I>host</I>
  -- forwarding to an IP-address based virtual server
<DD>notate that the target server is not a name based virtual hosting server.
With this option, all of servers of alias names or IP-addresses of the target
server are MOUNTed by this MOUNT rule.
It has been the default behavior of MOUNT but it can be changed with the
option HTTPCONF="<A HREF=#nvserv_auto>nvserv:auto</A>" to automatically detect
virtual servers in a set of MOUNT parameters.
This "avserv" option could become necessary to notate a non-virtual
server which is automatically guessed as a virtual server. 

<DT>rserv=<I>host</I>[:port]  -- real target server
<DD>specify the real host name or IP-address and port number of the target
server toward which the HTTP connection is established.
This option is used to do MOUNT a virtual hosting server of which virtual
host name is specified in the <I>rURL</I> rather than in the
"nvserv=<I>host</I>" option.
For example, the following two MOUNT rules are equivalent to each other.
<BR>
<KBD>&nbsp;MOUNT="/v/* http://www.domain/* rserv=192.168.1.123"</KBD><BR>
<KBD>&nbsp;MOUNT="/v/* http://192.168.1.123/* nvserv=www.domain"</KBD><BR>
Specifying the "rserv" option implies that the target server is a virtual
server as if notated with the "nvserv" option.

<DT>genvhost=<I>host</I>
 (obsoleted by nvserv and rserv options)
<DD>Specify the hostname which will be received by the target server
as its virtual hostname.
It is set in the "Host: <I>host</I>" field in the request message to be
forwarded to the server.
When the request is to be forwarded via a HTTP proxy, it is set
in the request URL as http://<I>host</I>/...
The default Host field sent to the server is derived from the
<A HREF="#MOUNT"><I>rURL</I></A>
part of the MOUNT parameter which specifies the target server.
For example for MOUNT="/* http://hosti:8080/*", "Host: hosti:8080"
will be forwarded to the server (which is running at the port hosti:8080).
To through pass the Host field in the request from a client to the server,
specify as "genvhost=-thru".
</DD>
</A>

<DT>ftosv=-cc-<I>charCode</I>
<DD>convert charset in HTTP header forwarded to server into
<I>charCode</I> (jis|sjis|euc|utf8)
</DD>

<A NAME="pathext">
<DT>pathext=<I>string</I>
<DD>
when DeleGate as an origin HTTP server searches a file for requested URL,
the path name extended with the specified <I>string</I> is retrieved first.
For example with "pathext=-ja", "index-ja.html" is retrieved prior to
"index.html".  It can be useful in combination with other MOUNT conditions,
like MOUNT="/* file:data/www/* nvhost=www.delegate.jp,pathext=-ja"
</DD>
</A>

</DL>

<A NAME=ex_vhost>
<P>
Example: virtual hosting, acting as multiple HTTP servers
<UL>
The target server or local directory is switched by with which name
the DeleGate is referred (in the "Host:vhost" header field).
In this example, requests for "http://dom1.com" and "http://dom2.org"
are forwarded to each corresponding server, while requests for
"http://dom3.net" or any other name are retrieved in each corresponding
local directory.
<P>
<KBD>
MOUNT="/* http://wwwA/* nvhost=dom1.com"<BR>
MOUNT="/* http://wwwB/* nvhost=dom2.org"<BR>
MOUNT="/* file:data/wwwC/* nvhost=dom3.net"<BR>
MOUNT="/* file:data/www/*"<BR>
</KBD>
</UL>
<P>
</A>

Example:<UL>
"useproxy", "method", "dst" and "withquery" options are introduced
originally to refuse potentially troublesome accesses which may invoke
CGI programs in target servers.  For example, to refuse any request
with POST method, or with URL including "?": 
<P>
<KBD>
MOUNT="http:* = method=POST,asproxy,useproxy"<BR>
MOUNT="http:* = withquery,asproxy,useproxy"<BR>
</KBD>
</UL>
</UL>
</A>


<A NAME=HTTP_AUTH TITLE="AUTH parameter for HTTP-DeleGate">
<P>
AUTH parameters for HTTP-DeleGate
<P>
<UL>
<DL>
<DT>AUTH=origin:auth
<DD>
-- default: AUTH=origin:ident<BR>
Like AUTH=proxy, specify using the value in "Authorization"
field in the HTTP header to authenticate the user, except
that accessibility to a DeleGate as a "HTTP origin server" is
checked in this case.
<P>
Example:<UL>
<KBD>AUTH=origin:auth RELIABLE="*@localhost"</KBD><BR>
Any user who can login to the localhost of this DeleGate,
giving a correct pair of user name and password in
Authorization, will be authorized to access.</UL>

<P>
<DT>AUTH=forward[:{by,for,ver,*}]
<DD>Put identification information of the source host in the Forwarded
field in a HTTP request header like:
<KBD>
<UL>
Forwarded: by <I>Me</I> (<I>Version</I>) for <I>Client</I>
</UL>
</KBD>
Currently, if this is specified, it is regarded as
AUTH="forward:*:" regardless of the second field.
This is useful for a DeleGate on a firewall which relays
internal HTTP servers toward outside .

<P>
<DT>AUTH=viagen[:<I>hostIdentifier</I>]
<DD>Specify the identifier of the host of this DeleGate, which is put into
the Via field in forwarded HTTP message headers as follows:
<UL><KBD>
Via: protocol-version <I>hostIdentifier</I> ( comment )<BR>
</KBD></UL>
If no AUTH=viagen is specified, a default pseudonym is used for
<I>hostIdentifier</I>.
If empty <I>hostIdentifier</I> is specified, as AUTH="viagen",
the hostname of this DeleGate is used.
A special specification AUTH="viagen:-" disables the insertion
of the Via field.<BR>
If '%' character is used in a <I>hostIdentifier</I>, it is interpreted
as the format for <A HREF="#authgen">authString</A> below.
</DD>

<A NAME=authgen TITLE="Authorization generation">
<P>
<DT>AUTH=authgen:basic:<I>authString</I>
<DD>Generate <KBD>"Authorization: Basic <I>authString</I>"</KBD>
in a HTTP request header to be forwarded to a server,
if it does not have an original Authorization field from a client.
The <I>authString</I> should be "<I>userName</I>:<I>passWord</I>".
The following special string stand for attributes of clients.
<P>
<UL>
<TABLE BORDER=0 CELLSPACING=0>
<TR><TD><KBD>%u</KBD><TD> -- user name got using Ident protocol
<TR><TD><KBD>%h</KBD><TD> -- host name of the client got from the socket
<TR><TD><KBD>%i</KBD><TD> -- host name of the network interface to the client
<TR><TD><KBD>%I</KBD><TD> -- like %i but use the value of "Host:" if given in HTTP
<TR><TD><KBD>%a</KBD><TD> -- host address of the client
<TR><TD><KBD>%n</KBD><TD> -- network address of the client
<TR><TD><KBD>%H</KBD><TD> -- hostname of the DeleGate
<TR><TD><KBD>%M</KBD><TD> -- the ADMIN of the DeleGate
<TR><TD><KBD>%A</KBD><TD> -- generated string by "CMAP=string:authgen:mapSpec"
<TR><TD><KBD>%U</KBD><TD> -- username part of client's [Proxy-]Authorization: username:password<BR>
<TR><TD><KBD>%P</KBD><TD> -- password part of client's [Proxy-]Authorization: username:password<BR>
</TABLE>
</UL>
<P>
Example:<UL>
When the firewall have two network interfaces and internal
and external hosts access from different interface, then
they can be distinguished by the name of interface.
<UL>
<KBD>
AUTH="authgen:basic:%i:%h"
</KBD>
</UL>
Otherwise, internal network should be explicitly defined
using CMAP as follows.
<UL>
<KBD>
AUTH="authgen:basic:%A"<BR>
CMAP="{internal:<I>passWord</I>}:authgen:*:*:{<I>InternalNetList</I>}"<BR>
CMAP="{external:<I>passWord</I>}:authgen:*:*:*"<BR>
</KBD>
</UL>
</UL>
<P>
A generated password is formatted as "<I>passWord</I>/%i" and
a DeleGate rejects incoming requests with an Authorization
field of such pattern. Thus forged password cannot pass the
DeleGate on the host "%i".
</DD>
</A>

<P>
<DT>AUTH=pauthgen:basic:<I>authString</I>
<DD>Generate <KBD>"Proxy-Authorization: Basic <I>authString</I>"</KBD>
like <A HREF="#authgen">AUTH=authgen</A>.<BR>
Note: obsoleted by <A HREF="#MYAUTH">MYAUTH</A>="<I>user</I>:<I>pass</I>:http-proxy".
<P>
Example:<UL>
Consume Proxy-Authorization in a request message from a client then
forward it to an upstream proxy as is (by <I>authString</I> == %U:%P)<BR>
<KBD>
AUTH=proxy:pauth AUTH="pauthgen:basic:%U:%P" PROXY=...
</KBD>
</UL>

<P>
<DT>AUTH=fromgen:<I>fromString</I>
<DD>If specified, "From: fromString" will be put in the HTTP
request if the original header does not have an original
From field.  If fromString is omitted, the default value
is "%u@%h".

<P>
<DT>AUTH=log:<I>remoteHost</I>:<I>identUser</I>:<I>authUser</I>
<DD>Specify contents of the client information part in common
logfile format of HTTP servers. The default value is
AUTH="log:%h:%u:%U".
<P>
<UL>
<TABLE BORDER=0 CELLSPACING=0>
<TR><TD><KBD>%F</KBD><TD> -- E-mail address in From field<BR>
<TR><TD><KBD>%L</KBD><TD> -- local part of From: local@domain field<BR>
<TR><TD><KBD>%D</KBD><TD> -- domain part of From: local@domain field<BR>
<TR><TD><KBD>%U</KBD><TD> -- username part of Authorization: username:password<BR>
<TR><TD><KBD>%P</KBD><TD> -- password part of Authorization: username:password<BR>
<TR><TD><KBD>%Q</KBD><TD> -- "for <I>clientFQDN</I>" part of Forwarded: field<BR>
</TABLE>
</UL>
<P>
Example:
 <UL>
 To record information about an original client in an internal
 DeleGate which is forwarded from a firewall DeleGate,
 generate From field at the firewall DeleGate and record it
 at the internal DeleGate.
 <P>        
 <KBD>
 <I>firewall</I>% delegated AUTH="fromgen:%u@%h" ...<BR>
 <I>internal</I>% delegated AUTH="log:%D/%h:%L/%u:%U" ...<BR>
 </KBD>
 </UL>
</DL>
</UL>
</A>
</A>

<A NAME=dgp TITLE="Configuration of DeleGate by Users">
<P>
Configuration of DeleGate by Users
<UL>
To make configuration of DeleGate be flexible,
allowing it not only to the administrator of the DeleGate
but also to the users (providers of WWW resources on an origin HTTP-DeleGate),
DeleGate supports reading user defined configuration parameters
at each request processing time.
Such parameters should be given in a files with file name extension ".dgp",
in the format of <A HREF="#Substitution">"+=parameters"</A> file,
on MOUNTed local file systems.
It works like <A HREF="#Fcgi">-Fcgi</A>
but more efficiently without creating a new process.

<P>
Example:
MOUNTing news server<I>N</I> at http://<I>delegate</I>/news/serv<I>N</I>/
<UL>
<DL>
<DT>
(1) by a parameter at the start-up time<BR>
MOUNT="/news/serv<I>N</I>/* nntp://<I>nntpserver<I>N</I></I>/*"
<P>
<DT>
(2) by a CGI-DeleGate<BR>
MOUNT="/news/* cgi:/<I>dirPath</I>/*"
<DD>
[the contents of file:/<I>dirPath</I>/serv<I>N</I>/welcome.cgi]
<BR>
delegated -Fcgi MOUNT="/* nntp://<I>nntpserver<I>N</I></I>/*"
<P>
<DT>
(3) by a ".dgp" file<BR>
MOUNT="/news/* file:/<I>dirPath</I>/*" 
<DD>
[the contents of file:/<I>dirPath</I>/serv<I>N</I>/welcome.dgp]
<BR>
MOUNT="/* nntp://<I>nntpserver<I>N</I></I>/*"
</DL>
</UL>
<P>
(This mechanism should be applied to other protocols like FTP...)
</UL>
</A>

<A NAME=SSI.shtml TITLE="Server Side Include in SHTML files">
<P>
Server Side Include in SHTML files
<UL>
On an origin HTTP-DeleGate, a local file with suffix ".shtml" is regarded,
like a file with ".html",
as a HTML file except that it includes special tags for
<I>Server Side Include</I> (SSI) and META which are to be
interpreted and substituted by the HTTP-DeleGate
before it is sent to a client.
<P>
SSI tags
<UL>
<DL>
<DT>&lt;!--#echo var="<I>varName</I>" --&gt;
<DD>
will be substituted with the value specified by <I>varName</I>.
<I>varName</I> can be arbitrary CGI compatible name like
"<KBD>REMOTE_HOST</KBD>" or "<KBD>HTTP_SERVER</KBD>",
as well as followings.
 <UL>
 <DL>
 <DT><KBD>DATE_GMT</KBD> -- current time in GMT
 <DT><KBD>DATE_LOCAL</KBD> -- current time local to the server host
 <DT><KBD>LAST_MODIFIED</KBD> -- the last modified time of the .shtml file
 <DT><KBD>REFERER</KBD> -- equiv. to HTTP_REFERER
 <DT><KBD>DOCUMENT_NAME</KBD> -- equiv. to SCRIPT_NAME
 <DT><KBD>DOCUMENT_URI</KBD> -- equiv. to REQUEST_URI
 <DT><KBD>*</KBD> -- all of variables as <I>name</I>=<I>value</I> pairs
 </DL>
 </UL>

<DT>&lt;!--#include virtual="<I>URL</I>" --&gt;
<DD>
will be substituted with the data specified by "virtual" attribute.
"virtual" can be full URL like "<I>proto</I>://<I>server</I>/<I>upath</I>"
or partial URL like "/<I>upath</I>" which will be interpreted
as http://<I>delegate</I>/<I>upath</I>.
Relative URLs like "<I>upath</I>" without leading "/"
are interpreted as relative to the base (current) shtml file.
<P>
<A NAME=RELAY_ssi>
Note that including a resource by SSI is under the access control of
DeleGate (as origin or proxy server) common to the access control
against client users.  That is, if a client user is forbidden to
access the included resource, it is also forbidden even via SSI-include.
<BR>
Especially allowing including a resource out of the DeleGate server,
with URL like <KBD>virtual=http://<I>exserver</I>/<I>dir</I>/<I>fileX</I></KBD>
can make a security hole made by a user as a SHTML writer.
In an origin server, relaying as a proxy must be forbidden by
<A HREF=#RELAY>RELAY</A>=no, but it also forbids SSI-include to do
from other servers.
<BR>
A simple workaround in version 9 is adding a limited RELAY as
<KBD>RELAY="proxy:http:<I>exserver</I>:*"</KBD> that only allows
relaying to <I>exserver</I>.
Another safer workaround is using MOUNT like
<KBD>MOUNT="/ex/* http://exserver/dir/*"</KBD> then write SSI-include like
<KBD>virtual="/ex/<I>fileX</I>"</KBD>.
But both of these allows client users to access to resources
other than the intended virtual URL in the <I>exserver</I>.
</A>
</DD>

<DT>&lt;!--#fsize virtual="<I>URL</I>" --&gt;
<DT>&lt;!--#flastmod virtual="<I>URL</I>" --&gt;
<DD>
will be substituted with the size or the last modified time
of the specified data respectively.
<DT>&lt;!--#config timefmt=<I>timeFormat</I> --&gt;
<DD>
will specify the format of generated time string by "#echo","#flastmod"
or so, in strftime(3) compatible format.
(default: timefmt="%a, %d %b %Y %H:%M:%S %z")
</DL>
</UL>
<P>
META tags
<UL>
<DL>
<DT>&lt;META HTTP-EQUIV=<I>fieldName</I> content="<I>fieldBody</I>"&gt;
<DD>
will generate "<I>fieldName</I>: <I>fieldBody</I>" header
in the HTTP response message.
The following patterns in <I>fileBody</I> will be substituted
as described above.
 <UL>
 <DL>
 <DT>${<I>varName</I>} or
     &lt;!--#echo var=<I>varName</I> --&gt;
 <DT>${flastmod:<I>URL</I>} or
     &lt;!--#flastmod virtual=<I>URL</I> --&gt;
 <DT>${fsize:<I>URL</I>} or
     &lt;!--#fsize virtual=<I>URL</I> --&gt;
 <DT>${include:<I>URL</I>} or
     &lt;!--#include virtual=<I>URL</I> --&gt;
 </DL>
 </UL>
<DT>Example:
<KBD>
 <DL>
 <DT>&lt;META HTTP-EQUIV=Status content="200 OK"&gt;
 <DT>&lt;META HTTP-EQUIV=Content-Type content="text/html"&gt;
 <DT>&lt;META HTTP-EQUIV=Pragma content="no-cache"&gt;
 <DT>&lt;META HTTP-EQUIV=Date content="${DATE_GMT}"&gt;
 <DT>&lt;META HTTP-EQUIV=Last-Modified content="${flastmod:URL}"&gt;
 </DL>
</KBD>
</DL>
</UL>
</UL>
</A>
</A>


<A NAME=serv_ICP TITLE="ICP proxy/server">
<P>
<B>ICP proxy/server</B>
<UL>
ICP-DeleGate provides remote clients with ICP service
about local CACHEDIR,
independently of contents server like HTTP-DeleGate
but sharing the same CACHEDIR.
See
<A HREF="http://www.delegate.org/delegate/icp/">http://www.delegate.org/delegate/icp/</A>
for more details.
<P>
Example: a couple of ICP and HTTP DeleGates sharing a CACHEDIR
<UL>
<KBD>
% delegated -P3130 SERVER=icp<BR>
% delegated -P8180 SERVER=http
</KBD>
</UL>
<P>
Example: an ICP proxy merging multiple upstream ICP servers
<UL>
<KBD>
% delegated -P3130 SERVER=icp ICP=<I>icpHost1</I>,<I>icpHost2</I>,...<BR>
</KBD>
</UL>
</UL>
</A>

<A NAME=ICPCONF TITLE="">
<PRE>
ICPCONF parameter*  ==  ICPCONF={<I>icpMaxima</I>|<I>icpConf</I>}
         <I>icpMaxima</I>  ==  para:<I>N</I>|hitage:<I>N</I>|hitobjage:<I>N</I>|hitobjsize:<I>N</I>|timeout:<I>N</I>
           <I>icpConf</I>  ==  <I>icpOptions</I>:<I>ProtoList</I>:<I>dstHostList</I>:<I>srcHostList</I>
                    --  default: ICPCONF=para:2,hitage:1d,...
</PRE>
<UL>
ICP configuration when the DeleGate server is running as an
ICP server (with SERVER=icp).
<P>
<TABLE BORDER=0 CELLSPACING=0>
<TR><TD>para:<I>N</I><TD> -- the number of parallel ICP-DeleGate servers [2]
<TR><TD>hitage:<I>N</I><TD> -- valid age of cached data to be notified as HIT [1d]
<TR><TD>hitobjage:<I>N</I><TD> -- valid age of cached data to be sent by HIT_OBJ [1h]
<TR><TD>hitobjsize:<I>N</I><TD> -- max. size of cached data by HIT_OBJ [1024](bytes)
<TR><TD>timeout:<I>N</I><TD> -- default timeout of waiting response [2.0](seconds)
<TR><TD>debug:<I>N</I><TD> -- the level of log for debug [0]
</TABLE>
</UL>
</A>


<A NAME=serv_FTP TITLE="FTP server">
<P>
<B>FTP proxy/server</B>
<UL>
Existing FTP clients without any proxying feature can use DeleGate
as a FTP proxy in two ways:
<UL>
<DL>
<DT><KBD>USER <I>user</I>@<I>host</I></KBD>
<DD>at login time,
enter the host name of a FTP server after user name.
<DT><KBD>CWD //<I>host</I>[/<I>path</I>]</KBD>
<DD>at any time,
enter the host name of a FTP server after "//" as if it is a directory
</DL>
</UL>
A user name can be followed by an account name as follows.
<UL>
<KBD>USER <I>user</I>~<I>account</I>@<I>host</I></KBD>
</UL>
<P>
Also the complete format
<KBD><I>user</I>:<I>pass</I>@<I>host</I>[:<I>port</I>]</KBD>
as the generic server specification in URL
is usable both for USER and CWD like follows.
<UL>
<KBD>USER ftp:<I>foo</I>%40<I>bar</I>@<I>server</I></KBD><BR>
<KBD>CWD //ftp:<I>foo</I>%40<I>bar</I>@<I>server</I>/<I>path</I></KBD><BR>
</UL>
<P>
On a multi-homed host, or on a host behind a firewall, the IP address
or port number used for data connections might have to be controlled by
<A HREF=#SRCIF>SRCIF</A>.
<P>
Example: proxy FTP-DeleGate<UL>
<KBD>
<I>firewall</I>% delegated -P8021 SERVER=ftp<BR>
</KBD>
<P>
Then you can connect to arbitrary FTP servers (which may be
outside of firewall) via this FTP-proxy.
<PRE>
<KBD>
<I>internal</I>% ftp
ftp> open <I>firewall</I> 8021
220- <I>firewall</I> PROXY-FTP server (DeleGate/6.1.0) ready.
220-   @ @
220-  ( - ) { DeleGate/6.1.0 (February 3, 2000) }
...
220- --
220- You can connect to a SERVER by `user' command:
220-    ftp> user username@SERVER
220- or by `cd' command (after logged in as an anonymous user):
220-    ftp> cd //SERVER
220- Cache is enabled by default and can be disabled by `cd .' (toggle)
220- This (proxy) service is maintained by '<I>admin</I>@<I>your.domain</I>'
220  
Name (yourhost:yourname): <B>ftp@ftp1</B>
331-- USER for ftp@ftp1.
220- <B>ftp1 FTP server ready</B>.
331- Guest login ok, send your complete e-mail address as password.
331--  @ @  
331  \( - )/ -- { connected to `ftp' }
Password: <B>me@my.domain</B>
230 Guest login ok, access restrictions apply.
ftp> <B>cd //ftp2</B>
250-- CWD for ftp@ftp2
220- <B>ftp2 FTP server ready</B>.
230- Guest login ok, access restrictions apply.
250--  @ @  
250  \( - )/ -- { connected to `ftp2' }
ftp> 
</KBD>
</PRE>

Note: The majority of ftp clients can allow to specify the port
number of FTP at command line like:<BR>
<KBD>
<I>internal</I>% ftp <I>firewall</I> 8021
</KBD>
</UL>

<P>
Example: cascaded FTP-Proxy
<UL>
<KBD>
<I>firewall</I># delegated -P21 SERVER=ftp PERMIT="ftp:*:<I>internal</I>"<BR>
<I>internal</I># delegated -P21 SERVER=ftp PROXY=<I>firewall</I>:21<BR>
</KBD>
</UL>

<P>
<A NAME=FTP_MOUNT>
Example: FTP MOUNT with filtering, merging and aliasing
<UL>
<KBD>
<DL>
<DT><I>firewall</I># delegated -P21 SERVER=ftp://serv1/ \<BR>
<DD>MOUNT="/pub2/* ftp://serv2/pub/*"
</DL>
</KBD>
<P>
This DeleGate relays the whole contents of serv1 except for "/pub2/*"
which is replaced by that of "ftp://serv2/pub/*"
</UL>
</A>

<P>
Example: MOUNT to non-anonymous FTP (and sftp) server
<UL>
<KBD>
MOUNT="/sv0/* ftp://serv0/*"<BR>
MOUNT="/sv1/* ftp://serv1/%2F*"<BR>
MOUNT="/sv2/* ftp://serv2/%2F* logindir"<BR>
</KBD>
<BR>
The url-path in the URL of FTP (as ftp://server/url-path) is interpreted
as the relative path from the login-directory of a user (RFC1738).
The absolute path from the root directory in the server is to be represented
as ftp://server/%2Fabs-url-path where "%2F" represents the url-encoded
string of "/" for the root directory.
In the case of MOUNT for non-anonymous FTP (and sftp) server, it is usual
that a login-directory is not the root directory in the server.
In the above examples of MOUNTs, the first one shows only the directory tree
under a login-directory while the second one shows the whole directory tree
under the root.
This becomes necessary to allow users to access to the whole directory
and/or to do cache data of non-anonymous users.
The third one with "logindir" option shows the whole tree but the current
directory right after login is set to the login-directory.
</UL>

<A NAME=serv_LPR TITLE="LPR over FTP gateway">
<P>
Example: FTP to LPR (Line Printer Daemon Protocol) gateway
<UL>
<KBD>
MOUNT="/*     lpr://<I>printer0</I>/queue0/*"<BR>
MOUNT="/pr1/* lpr://<I>printer1</I>/queue1/*"<BR>
MOUNT="/pr2/* lpr://<I>printer2</I>/queue2/*"<BR>
</KBD>
<P>
A LPR/FTP-DeleGate allows FTP clients to access to remote printers;
printing a file by FTP file uploading and
showing a printer status by FTP directory listing.
MountOption "readonly" will inhibits listing the status.
</UL>
</A>

<P>
Example: origin FTP-DeleGate<UL>
<KBD>
host# delegated -P21 SERVER=ftp MOUNT="/* /path/of/root/*" RELAY=no<BR>
</KBD>
<P>
"RELAY=no" prohibits the DeleGate to work as a proxy FTP server.
Writing to the file is disabled by default in origin FTP-DeleGate.
You need to specify "rw" (read/write) as a mount option to
MOUNT points to be writable, like MOUNT="/xxx/* /yyy/* rw".
<BR>
Retrieving the whole contents under a specified <I>directory</I> and
returning it as a single file in tar format
by "RETR <I>directory</I>.tar" command is supported to be
enabled by adding "tar" to the REMITTABLE list like REMITTABLE="+,tar".
</UL>
</UL>

<A NAME=FTPCONF>
<PRE>
FTPCONF parameter*  ==  FTPCONF=<I>ftpControl</I>[:{sv|cl}]
           <I>ftpControl</I>  ==  nopasv | noport | noxdc | rawxdc
                    --  default: none
</PRE>
<UL>
<DL>
<DT>nopasv
<DD>disables PASV command for data connection.
<DT>noport
<DD>disables PORT command for data connection.
<DT>noxdc
<DD>disables XDC mode for data transmission on control connection.
<DT>rawxdc
<DD>transmit data without encoding into BASE64 on XDC mode
</DL>
<P>
If a <I>ftpControl</I> listed above is followed by ":sv" or ":cl" like "nopasv:sv"
for example, the <I>ftpControl</I> is applied only for server side
or client side respectively.
<P>
<DL>
<DT>doepsv:sv
<DD>
use EPSV (instead of PASV) with FTP servers
<DT>doeprt:sv
<DD>
use EPRT (instead of PORT) with FTP servers
</DD>
<P>
<A NAME=ftp-bounce>
<DT>bounce:{no|do|th|cb|rl}
<DD>
-- default: FTPCONF=bounce:no <BR>
controls how to manipulate <A HREF=http://www.cert.org/advisories/CA-1997-27.html>FTP Bounce</A>.
 <DL>
 <DT><KDB>no</KBD> -- reject any FTP Bounce <BR>
 <DT><KDB>do</KBD> -- permit any FTP Bounce <BR>
 <DT><KDB>th</KBD> -- don't care FTP Bounce (backward compatible) <BR>
 <DT><KDB>cb</KBD> -- convert FTP Bounce to "EPRT |||port|" <BR>
 <DT><KDB>rl</KBD> -- reject FTP Bounce from specific clients in combination with <KBD>REJECT="ftp-bounce</KBD>:*:<I>clientHost</I>" parameter<BR>
 </DL>
</DD>
</A>

<DT>forcexdc
<DD>enables XDC mode even if the destination server is on the same host

<DT>proxyauth
<DD>
enables authentication and authorization as a proxy FTP server.
A username as <I>user</I>@<I>server</I> is decomposed into
<I>user</I> and <I>server</I> and used for matching in
<A HREF=#AUTHORIZER>AUTHORIZER</A> as
AUTHORIZER=-list{<I>user</I>:<I>pass</I>}(<I>reprUser</I>):ftp:<I>server</I>".
Also it enables generation of authentication information to be forwarded
to the server by <A HREF=#MYAUTH>MYAUTH</A> as
MYAUTH="<I>genuser</I>:<I>genpass</I>:ftp:<I>server</I>:-a/<I>user</I>@*".

<DT>servon=init|user|pass
<DD>
select the timing of connection establishment to the MOUNTed server.
By default, the connection to a server is initiated on the command
from the client, of which argument selects the MOUNT point, after
the authentication finished (with USER and PASS).
servon="init" forces immediate connection to a server on the client
connection and doing authentication by the server (as SERVER=ftp://server).
"user" or "pass" specifies connecting to a server on "USER" or "PASS"
command respectively.

<DT>usdelim:{setOfDelimiters}
<DD>
-- default: FTPCONF="usdelim:*%#" <BR>
a set of delimiters usable in place of "@" in "user@site",
ex. "ftp://user*server@proxy" or "ftp://anonymous:name*domain@server".
<DT>hideserv
-- hide server's identification
<DD>
Don't relay the opening message from the server to client which may
include the identification information about the server.
<!--
<DT>dfltuser:<I>username</I>
-- the default user name to be used to do login to the server [anonymous]
<DD>
A user name on a server can be unspecified if a login to the server
is not caused by "USER <I>username</I>@<I>server</I>" command sent
from a client.
For example, a login to a server may be caused without user name
by "CWD //server" command from a client,
or a retrieval for a file mounted by MOUNT="/* ftp://server/*",
and so on.
In these cases, the user name is determined depending on the current status
of the login to the server.  If a client is already doing login to a server
with an explicit user name, the name is used.
Otherwise, the <I>username</I> defined by this option, or "anonymous"
by default, is used.
-->
<DT>nounesc
-- disables unescaping %<I>XX</I> notation in arguments to the server.
<DD>
If this option is not specified, %<I>XX</I> notation included in arguments
representing path, like "%2Fhome/" for example, is unescaped by default.
</DL>
<P>
<KBD>FTPCONF</KBD> can be applied on a specific condition by specifying it
as a <A HREF=#MountOptions><I>MountOption</I></A> like
<NOBR><KBD>MOUNT="</KBD><I>vURL rURL</I> <KBD>FTPCONF=</KBD><I>ftpConf</I>"</NOBR>
or with <A HREF=#CMAP><KBD>CMAP</KBD></A>
like <KBD>CMAP=</KBD><I>ftpConf</I><KBD>:FTPCONF:</KBD><I>connMap</I>.
</UL>
</A>

<A NAME=xferlog TITLE="FTP Transfer Log Format">
<P>
FTP Transfer Log Format<BR>
<UL>
The format of PROTOLOG for FTP protocol is so called <I>xferlog</I>(5)
which is compatible with that of "wu-ftp".
Each line of xferlog consists of following elements (in a single line).
<P>
<DL>
<DT>
<I>currentTime</I> <I>transferTime</I> <I>clientHost</I><BR>
<DD>
<I>fileSize</I> <I>fileName</I> <I>transferType</I>
<I>specialActionFlag</I> <I>direction</I> <I>accessMode</I><BR>
<I>userName</I> <I>serviceName</I> <I>authenticationMethod</I>
<I>authenticatedUserID</I>
<I>DeleGateStatus</I>
</DL>
<P>
<I>transferTime</I> is the total time in seconds for the transfer.
<I>transferType</I> is either "a" (ascii) or "b" (binary).
<I>specialActionFlag</I> is always "_" (none) in the current implementation.
<I>direction</I> is either "o" (outgoing) or "i" (incoming).
<I>accessMode</I> is either "a" (anonymous) or "r" (real user).
<I>userName</I> is e-mail address with <I>accessMode</I> "a",
or a real user name with <I>accessMode</I> "r".
<I>serviceName</I> is always "ftp" in the current implementation.
<I>authenticationMethod</I> is either "0" (none) or "1" (<A HREF="ftp://ftp.ietf.org/rfc/rfc1413.txt">RFC1413</A> Authentication).
<I>authenticatedUserID</I> is the user id got via the <I>authenticationMethod</I>
or "*" without authentication.
<I>DeleGateStatus</I> is one of "L" (local file), "H" (cache hit),
"N" (cache miss).
<P>
Example:<UL>
<DL>
<DT>Mon Feb 28 15:32:15 2000 13 proxy.xyz.co.jp
<DD>182558 /ftp/pub/DeleGate/Manual.htm a _ o a<BR>
    webmaster@xyz.co.jp ftp 0 * L
</DL>
</UL>
</UL>
</A>
</A>

</UL>
<A NAME=serv_Telnet TITLE="Telnet proxy/server">
<P>
<B>Telnet proxy/server</B>
<P>
<UL>
Telnet-DeleGate can relay X Window protocol as well as Telnet protocol
in similar way to FWTK.
<P>
Example: proxy Telnet-DeleGate<UL>
<KBD>
<I>firewall</I>% delegated -P8023 SERVER=telnet <A HREF="#TIMEOUT-io">TIMEOUT</A>=io:1h
</KBD>
<P>
Then you can connect to arbitrary Telnet server via this Telnet-proxy.
<PRE><KBD><I>internal</I>% telnet <I>firewall</I> 8023
...
--  @ @  <I>firewall</I> PROXY-telnet server DeleGate/6.1.0
-- ( - ) { Hit '?' or enter `help' for help. }
...
-- -- -- This (proxy) service is maintained by '<I>admin</I>@<I>your.domain</I>'
>> Host name: <B>exthost</B>
-- Connected to exthost.

SunOS UNIX (exthost)
login: 
</KBD>
</PRE>
</UL>

<P>
Example: origin Telnet-like server
<UL>
<KBD>
C:\> delegated -P23 SERVER=exec XFIL=command.com WORKDIR="/"
</KBD>
<BR>
// Use command.com of Windows95/98 as a simple telnet server.
</UL>
</UL>
</A>

<P>
<A NAME=SSH_via_Telnet TITLE="Telnet gateway to SSH server">
<P>
<B>SSH/Telnet gateway</B>
<P>
<UL>
In the Telnet-DeleGate (DeleGate server for Telnet clients), a host name
prefixed with "-ssh" and "." (as "-ssh.<I>host</I>") implies a SSH server
on the <I>host</I>.
In access to such a server, Telnet-DeleGate works as a gateway between
the SSH server and a Telnet client.
For example, using a Telnet-DeleGate configured like follows,
Telnet clients can login to a SSH server on <I>host</I> as <I>user</I>
as follows:
<UL>
<KBD>
  % delegated -P8023 SERVER=telnet://-ssh<BR>
  % telnet -l <I>user</I>@<I>host</I> localhost 8023<BR>
</KBD>
</UL>
The target SSH server can be limited as this:
<UL>
<KBD>
  % delegated -P8023 SERVER=telnet://-ssh.<I>host</I><BR>
  % telnet -l <I>user</I> localhost 8023<BR>
</KBD>
</UL>
The user on the target SSH server can be limited as this:
<UL>
<KBD>
  % delegated -P8023 SERVER=telnet://<I>user</I>@-ssh.<I>host</I><BR>
  % telnet localhost 8023<BR>
</KBD>
</UL>
The password of the user can be specified as this:
<UL>
<KBD>
  % delegated -P8023 SERVER="telnet://<I>user</I>:<I>pass</I>@-ssh.<I>host</I>"<BR>
  % telnet localhost 8023<BR>
</KBD>
</UL>
In this case, the Telnet client cannot specify anything about the target
SSH server and the login procedure is achieved fully automatically.
Reserved characters in the <I>pass</I> part should be escaped with
the "%XX" notation (at least "@" must be escaped with "%40").
<BR>
Telnet clients without the capability to send authentication information
with the "-l <I>user</I>" option or so, can specify it in the traditional way
of the Telnet-DeleGate as follows:
<UL>
<KBD>
  % delegated -P8023 SERVER=telnet://-ssh<BR>
  % telnet localhost 8023<BR>
  >> Host name: <I>user</I>@<I>host</I><BR>
</KBD>
</UL>
</UL>
</A>


<A NAME=serv_POP TITLE="POP proxy">
<P>
<B> POP proxy</B>
<UL>
<P>
Example: proxy POP-DeleGate
<UL>
<KBD>
<I>firewall</I># delegated -P110 SERVER=pop<BR>
<P>
<I>external</I>% telnet <I>firewall</I> pop<BR>
+OK Proxy-POP server (DeleGate6.1.0) at <I>firewall</I> starting.<BR>
<B>USER <I>username</I>@<I>servername</I></B><BR>
...<BR>
Instead of "@", "%" or "#" can be used as the delimiter between
<I>username</I> and <I>servername</I>, like
<B><I>username</I>%<I>servername</I></B> or
<B><I>username</I>#<I>servername</I></B>.
</KBD>
</UL>

<P>
Example: POP MOUNT<BR>
<UL>
"pop://<I>user</I>@<I>server</I>" is represented
as "pop://<I>server</I>/<I>user</I>" internally thus
it can be controlled by MOUNT as follows:
<P>
<KBD>MOUNT="//*      ="</KBD>
... don't rewrite if a server is specified by the user<BR>
<KBD>MOUNT="*        pop://<I>defaultHost</I>/*"</KBD>
... specify default POP server<BR>
<KBD>MOUNT="user1    pop://host1/*"</KBD>
... let the "host1" be the server of "user1"<BR>
<KBD>MOUNT="//pop2/* pop://host2/*"</KBD>
... map <I>user</I>@pop2 to <I>user</I>@host2, hiding real hostname "host2"<BR>
<KBD>MOUNT="<A HREF=#MountComplex><KBD>//*%S/%S</KBD></A> pop://server/*%(1)@%(0)"</KBD>
... forward <I>user</I>@<I>host</I> as is to pop://server/<I>user</I>@<I>host</I><BR>
</UL>
<P>
When a target POP server indicates that it accepts APOP authentication
(by a greeting message with a time stamp), DeleGate tries login with
APOP first, then retries with USER+PASS when APOP failed.
But if a server never accepts APOP in spite of its greeting, the useless
trial with APOP can be suppressed by "noapop" MountOption like this:
<P><UL><KBD>
MOUNT="* pop://<I>server</I>/* noapop"
</KBD></UL>

<P>
Example: NNTP server to POP client gateway
<UL>
<KBD>
SERVER=pop<BR>
MOUNT="* nntp://nntpserver/*"<BR>
MOUNT="ns2-* nntp://nntpserver1/* apop=password"<BR>
MOUNT="ns3-* nntp://nntpserver2/* pass=password"<BR>
</KBD>
<P>
Clients are expected to send a newsgroup name as a user name.
</UL>

<P>
Example: POP server to HTTP client gateway
<UL>
<KBD>
<I>firewall</I># delegated -P80 MOUNT="/mail/* pop://<I>mailHost</I>/*"
</KBD>
<P>
This DeleGate provides mailboxes in POP server (at <I>mailHost</I> by
default) to HTTP clients.  Clients accessing to
"<KBD>http://<I>firewall</I>/mail/</KBD>"
are required to enter Username and Password for POP server at <I>mailHost</I>
as authorization information on HTTP.  If Username is in the form
"<I>user</I>@<I>mailHost2</I>",
not <I>mailHost</I> but <I>mailHost2</I> is accessed as
a target POP server.
Each mailbox of User at Host server is named as
"<KBD>http://<I>firewall</I>/mail/+pop.User.Host</KBD>",
thus you can directly specify User and Host in URL.
</UL>
</UL>
</A>

<A NAME=serv_IMAP TITLE="IMAP proxy">
<P>
<B>IMAP proxy</B>
<UL>
Example: proxy IMAP-DeleGate<UL>
<KBD>
<I>firewall</I># delegated -P143 SERVER=imap<BR>
<P>
<I>external</I>% telnet <I>firewall</I> imap<BR>
* OK external Proxy-IMAP server DeleGate/6.1.15<BR>
<B>C001 LOGIN <I>username</I>@<I>servername</I></B><BR>
...<BR>
LOGIN <I>username</I>%<I>servername</I> is also acceptable.
</KBD>
</UL>
</UL>
</A>


<A NAME=serv_SMTP TITLE="SMTP proxy/server">
<P>
<B>SMTP proxy/server</B>
<UL>
<P>
Example: proxy SMTP-DeleGate<UL>
// with aliasing and filtering<BR>
<KBD>
<DL>
<DT><I>firewall</I># delegated -P25 SERVER=smtp://mail-server/ \<BR>
<DD>MOUNT="foo@bar smtp://foo2@bar2" \<BR>
    MOUNT="* smtp://-"<BR>
</DL>
</KBD>
</UL>
</UL>

<A NAME=SMTPCONF TITLE="">
<PRE>
SMTPCONF parameter* ==  SMTPCONF=<I>what</I>:<I>conf</I>
                    --  default: SMTPCONF=bgdatasize:64K
</PRE>
<UL>
<DL>
<DT>myname:<I>name</I>
<DD>
Specify the name of this host to be shown to client or server in
its opening message, HELO command, and so on.

<DT>reject:{nohelo,nofrom,pipeline,nomx,notselfmx,notmxhelo}
<DD>
Reject the DATA or the session if a specified condition is true.
<UL>
<DL>
<DT>"nohelo" -- the client does not say "HELO"
<DT>"nofrom" -- the client does not say "MAIL FROM"
<DT>"pipeline" -- the client send command without waiting server's response
<DT>"nomx" -- the client's host does not have a MX record
<DT>"notselfmx" -- the client's host is not the MX of itself
<DT>"notmxhelo" -- the domain in the HELO is not the MX of the client's host
</DL>
</UL>
Multiple conditions can be specified concatenated with "+" as
<KBD>SMTPCONF="reject:nomx+nohelo+nofrom+pipeline"</KBD>.

<DT>bgdatasize:<I>N</I>
<DD>
If the data is larger than <I>N</I> bytes, relay it in background. 
This means relaying a "DATA" command to a server without having a client
wait for the response for "QUIT" command from the server.
Note that only one mail DATA can be relayed in background and the mail
can be lost if the DeleGate crashes before finishing the forwarding
because the current DeleGate have no mechanism for spooling and
retransmission.

<DT>maxrcpt:<I>N</I>
<DD>
Limit the acceptable maximum number of recipients (by RCPT commands)
</DD>

<A NAME=MX_routing>
<DT>MX:<I>server</I>[:<I>domain</I>]
<DD>
Specify the SMTP server toward which mails
(bound for the <I>domain</I>) are forwarded.
The server can be specified based on the destination address of the
E-mail to be relayed (it is the address indicated in the RCPT command
on the SMTP protocol).
The character "*" in <I>server</I> is replaced with the
<I>domain</I> part of a E-mail address as "<I>foo</I>@<I>domain</I>".
The prefix <KBD>"-MX."</KBD> to a domain name as <KBD>"-MX.domain"</KBD>
represents the mail-exchange server of the domain
(which is retrieved by DNS as the MX record of the domain or host).<BR>
The default specification is
<KDB>SMTPCONF="MX:{-MX.*,*}"</KBD>
which means trying the MX first, and if it failed, then try direct
connection to the domain as a hostname.
<P>
Examples:<BR>
<KDB>SMTPCONF="MX:smtpserver"</KBD>
 -- use the smtpserver as the upstream SMTP server<BR>
<KDB>SMTPCONF="MX:{smtpserver1,smtpserver2}"</KBD>
 -- try the SMTP servers in the order<BR>
<KDB>SMTPCONF="MX:{-MX.*,*}"</KBD>
 -- the default configuration<BR>
<KDB>SMTPCONF="MX:{-MX.*,*,smtpserver}"</KBD>
 -- adding a backup SMTP server<BR>
<KDB>SMTPCONF="MX:{*,-MX.*}:*.localdomain"</KBD>
 -- forward directly to the host if it's in localdomain<BR>
<KDB>SMTPCONF="MX:smtpserver:{*.dom1,*dom2}"</KBD>
 -- a server for the specified domains<BR>
</DD>
</A>

<DT>callback<KBD>[:[<I>T</I>][:<I>srcHostList</I>]]</KBD>
<DD>
Callback to the SMTP server on the client host which is making
current request (on HELO command).
If there is not a SMTP server on the client host, then the
processing of the request will be delayed up to <I>T</I> seconds.
This could be effective to reduce DDoS type SPAM messages which
are relayed exploiting non-SMTP servers.
SMTPCONF="callback" is the abbreviation of <KBD>SMTPCONF="callback:20:*"</KBD>.

<DT>bcc:<KBD><I>emailAddr</I>[:<I>srcHostList</I>]</KBD>
<DD>
Append the <I>emailAddr</I> to the list of recipients.

</DL>
</UL>
</A>

<A NAME=SMTPGATE TITLE="">
<PRE>
SMTPGATE parameter  ==  SMTPGATE=<I>dirPath</I>
                    --  default: SMTPGATE='${ETCDIR}/smtpgate'
</PRE>
<UL>
Specify the configuration directory for SMTPGATE,
a SMTP to {SMTP,NNTP} gateway.
To accept and relay SMTP messages bound to
"<I>recipient</I>@<I>the-host-of-DeleGate</I>",
create a configuration directory at
"SMTPGATE/users/<I>recipient</I>"
for each <I>recipient</I>,
to hold files for configuration, log, counter, and spool.
Then create a configuration file named "SMTPGATE/users/<I>recipient</I>/conf".
<P>
Example: SMTP to SMTP forwarding
<UL>
// forward messages accepted at "feedback@delegate.org"<BR>
// toward "delegate-en@smtpgate.etl.go.jp"<BR>
<P>
<KBD>
delegate.org# delegated -P25 SERVER=smtp
</KBD>
<P>
[the contents of SMTPGATE/users/feedback/conf]
<UL>
<KBD>
INHERIT: sendmail<BR>
SERVER-HOST: mail.etl.go.jp<BR>
RECIPIENT: delegate-en@smtpgate.etl.go.jp<BR>
ACCEPT/From: !%, !MAILER_DAEMON@, !hotmail.com, ...
</KBD>
</UL>
</UL>

<P>
Example: SMTP to NNTP forwarding
<UL>
[the contents of SMTPGATE/users/feedback/conf]
<UL>
<KBD>
INHERIT: postnews<BR>
SERVER-HOST: news.delegate.org<BR>
OUTPUT/Newsgroups: mail-lists.delegate-en<BR>
OUTPUT/Distribution: world<BR>
OUTPUT/Reply-To: feedback@delegate.org<BR>
OUTPUT/Subject: [DeleGate-En] ${subject:hc}<BR>
OUTPUT/Header: X-Seqno: ${seqno}<BR>
OUTPUT/Header: UNIX-From: ${unixfrom}<BR>
CONTROL/Errors-To: mladmin@delegate.org<BR>
ACCEPT/User-Text: delegate </KBD>## reject if a word "delegate" is not in body<KBD><BR>
ACCEPT/Max-Bytes: 50000 </KBD>## reject larger 50KB header+body<KBD><BR>
ACCEPT/Min-Body-Bytes: 64 </KBD>## reject smaller 64B body<KBD><BR>
OPTION: isn,rni,res,reb<BR>
</KBD>
</UL>
</UL>

<P>
A SMTPGATE configuration file consists of a series of lines
of directives,
each looks like a message header of the internet message.
Comment string after sharp (#) character in each line is ignored.
Directives are categorized into three groups;
CONTROL, ACCEPT and OUTPUT.

<P>
<DL>
<DT>CONTROL
<DD>
Specify the function of the gateway, the destination server,
and the destination address in the envelope.
Note that you can inherit a configuration from another <I>recipient</I>
as well as "sendmail" and "postnews" in the INHERIT directive.
<P>
<DL>
<DT><KBD>INHERIT</KBD>: {sendmail | postnews | <I>recipient</I>}
<DT><KBD>SERVER-HOST</KBD>: <I>host</I>
<DT><KBD>SERVER-PORT</KBD>: <I>portNumber</I>
<DT><KBD>RECIPIENT</KBD>: <I>EmailAddressForm</I> (used with "sendmail")
<DT><KBD>CONTROL/SENDER</KBD>: <I>EmailAddressForm</I> (envelope's From in SMTP)
<DT><KBD>CONTROL/BCC</KBD>: <I>EmailAddressForm</I> (a copy is sent to the address on success)
<DT><KBD>CONTROL/Errors-To</KBD>: <I>EmailAddress</I> (a copy is sent to the address on error or rejection)
<DT><KBD>ARCHIVE</KBD>: <I>archiveFileNameForm</I>
<DT><KBD>MYAUTH</KBD>: <I>username</I>:<I>password</I> (AUTHINFO for NNTP server)
<DT><KBD>OPTION</KBD>: <I>OptionList</I>
<UL>
<KBD>isn</KBD> -- Increment Sequence Number (to be referred by ${seqno})<BR>
<KBD>rni</KBD> -- Reject No message-Id<BR>
<KBD>res</KBD> -- Reject Empty Subject<BR>
<KBD>reb</KBD> -- Reject Empty Body<BR>
<KBD>axo</KBD> -- Append X-Original headers<BR>
<KBD>rxo</KBD> -- Remove X-Original headers<BR>
<KBD>gwt</KBD> -- GateWay Trace<BR>
<KBD>ntr</KBD> -- Do NOT add trace field (Received:)
</UL>
</DL>
<P>
<DT>ACCEPT
<DD>
If specified, only messages which have fields
matching with specified patterns are accepted.
<P>
<DL>
<DT><KBD>ACCEPT/Sender</KBD>: <I>ListOfEmailAddressPattern</I>
<DT><KBD>ACCEPT/Recipient</KBD>: <I>ListOfEmailAddressPattern</I>
<DT><KBD>ACCEPT/From</KBD>: <I>ListOfEmailAddressPattern</I>
<DT><KBD>ACCEPT/To</KBD>: <I>ListOfEmailAddressPattern</I>
<DT><KBD>ACCEPT/Max-Bytes</KBD>: <I>messageSize</I>
<DT><KBD>ACCEPT/Min-Body-Bytes</KBD>: <I>bodySize</I>
<DT><KBD>ACCEPT/Max-Exclams</KBD>: <I>theNumberOfExclamationMarks</I>
<DT><KBD>ACCEPT/User-Text</KBD>: <I>listOfWords</I> (in Subject or body)
<DT><KBD>REJECT/User-Text</KBD>: <I>listOfWords</I> (in Subject or body)
<DT><KBD>ACCEPT/Content-Type</KBD>: <I>listOfTypesOrCharsets</I>
<DT><KBD>ACCEPT/Client-Host</KBD>: <I>srcHostList</I>
</DL>
<P>
<DT>OUTPUT
<DD>
Header fields to be put into the output messages
replacing the original fields in the input message.
<P>
<DL>
<DT><KBD>Newsgroups</KBD>: <I>fieldBodyForm</I> (to be used with "postnews")
<DT><KBD>Distribution</KBD>: <I>fieldBodyForm</I> (to be used with "postnews")
<DT><KBD>Reply-To</KBD>: <I>fieldBodyForm</I>
<DT><KBD>To</KBD>: <I>fieldBodyForm</I>
<DT><KBD>Subject</KBD>: <I>fieldBodyForm</I>
<DT><KBD>Header</KBD>: <I>fieldName</I>: <I>fieldBodyForm</I>
<DT><KBD>FILTER</KBD>: <I>filterCommand</I>
</DL>
<P>
<DT>Substitution
<DD>
The following patterns appearing in ...<I>Form</I> in field body part
of directives are substituted with the values in the header
or the envelope of the input message.
<P>
<DL>
<DT><KBD>${sender}</KBD> -- <I>sender</I> in the envelope (in RCPT To)
<DT><KBD>${recipient}</KBD> -- <I>recipient</I> in the envelope (in MAIL From)
<DT><KBD>${recipient.name}</KBD> -- local name part of the <I>recipient</I>
<DT><KBD>${recipient.mx}</KBD> -- Mail eXchanger of the <I>recipient</I>
<DT><KBD>${header.<I>field</I>}</KBD> -- body of header <I>field</I> in the input message
<DT><KBD>${from}</KBD> -- From field in the input message
<DT><KBD>${unixfrom}</KBD> -- Unix-From string for the <I>recipient</I>
<DT><KBD>${subject}</KBD> -- Subject field in the input message
<DT><KBD>${subject:hc}</KBD> -- <I>head-cleaned</I> Subject field
<DT><KBD>${seqno}</KBD> -- sequence number
<DT><KBD>${seqno/10}</KBD> -- sequence number / 10 (used with ARCHIVE)
<DT><KBD>${seqno/100}</KBD> -- sequence number / 100 (used with ARCHIVE)
<DT><KBD>${date+<I>format</I>}</KBD> -- formatted string of current time (used with ARCHIVE)
</DL>
</DL>

<P>
When a SMTP-DeleGate received a message bound for a recipient,
with an address formed as <I>recipient</I>@<I>mailhost</I>,
it retrieves the configuration file for the <I>recipient</I>
in the following two directories in the order.
<P>
<UL>
<DL>
<DT>SMTPGATE/users/<I>recipient</I>/
<DT>SMTPGATE/admin/<I>recipient</I>/
</DL>
</UL>
<P>
If no configuration for the <I>recipient</I> is found,
then the default configuration is used if it exists at the following directory.
<P>
<UL>
SMTPGATE/admin/@default/
</UL>
<P>
Otherwise the built-in default configuration is used.
The default is at "/-/builtin/config/smtpgate/@default/conf"
which can be <A HREF="#customize">customized</A> with MOUNT option.
The contents of the default is like follows which means
just delivering the input message
to the address of the recipient via the mail exchanger of the recipient.
<P>
<UL>
<KBD>
CONTROL/INHERIT:     sendmail<BR>
CONTROL/RECIPIENT:   ${recipient}<BR>
CONTROL/SERVER-HOST: ${recipient.mx}<BR>
</KBD>
</UL>

<P>
The directory for each <I>recipient</I> contains following files.
<P>
<UL>
<DL>
<DT><I>recipient</I>/conf  -- configuration file
<DT><I>recipient</I>/log   -- log file
<DT><I>recipient</I>/count -- counter file for ${seqno} (optional)
<DT><I>recipient</I>/spool/ -- archive directory of relayed messages (optional)
<DT><I>recipient</I>/rejected/ -- archive directory of rejected ones (optional)
</DL>
</UL>
<P>
Optional ones will be enabled by manually creating the file or the directory.
Instead of the default archive file,
user can define the file name and the unit of archive by ARCHIVE directive.
<P>
Example:
<UL>
<KBD>
<DL>
<DT>ARCHIVE: spool/%05${seqno}-${date+%Y%m%d-%H%M%S}-%05${pid}<BR>
<DD>## default archive enabled if spool/ exists<BR>
<DT>ARCHIVE: arc-${seqno} ## archive with sequence number<BR>
<DT>ARCHIVE: arc-%4${seqno/10} ## an archive file per every 10 messages<BR>
<DT>ARCHIVE: arc-${date+%Y-%m} ## an archive file per month<BR>
</DL>
</KBD>
</UL>

</UL>
</A>
</A>


<A NAME=serv_NNTP TITLE="NNTP proxy/server">
<P>
<B>NNTP proxy/server</B>
<P>
<UL>
MOUNT can be applied to NNTP-DeleGate, for filtering and aliasing of
newsgroups, and for merging multiple NNTP severs.
For example,
MOUNT="alias-group. nntp://server/group."
specifies to passing newsgroups "group.*" and aliases
them into "alias-group.*".
A simple filtering specification is
SERVER="nntp://server/group."
which is equivalent to
MOUNT="= nntp://server/group.".
If multiple MOUNT for multiple NNTP servers, then the DeleGate
merges the newsgroups on the servers, and serves the newsgroups
to a client as if they are on a single server.
<P>
Example: Filtering<UL>
<KBD>
# delegated -P119 SERVER=nntp://<I>nntpServer</I>/<I>group</I>.
</KBD>
<P>
relays only newsgroups which have name pattern "<I>group</I>.*".
A list of groups can be specified for a <I>nntpServer</I> like
"nntp://<I>nntpServer</I>/<I>group1</I>.,<I>group2</I>.,..."
</UL>

<P>
Example: merge multiple NNTP servers<UL>
<KBD>
<DL>
<DT># delegated -P119 SERVER=nntp \<BR>
<DD>MOUNT="= nntp://<I>server1</I>/"<BR>
    MOUNT="= nntp://<I>server2</I>/"
</DL>
</KBD>
</UL>

<P>
Example: merge multiple NNTP servers with authentication (by AUTHINFO)<UL>
<KBD>
<DL>
<DT># delegated -P119 SERVER=nntp \<BR>
<DD>MOUNT="= nntp://<I>user1</I>:<I>pass1</I>@<I>server1</I>/"<BR>
    MOUNT="= nntp://<I>user2</I>:<I>pass2</I>@<I>server2</I>/"
</DL>
</KBD>
</UL>

<P>
Example: mount selected group(s)
<UL>
// mounts groups of group.* with it original names.<BR>
<KBD>
MOUNT="= nntp://<I>server1</I>/<I>group</I>."
</KBD>
<BR>
// mounts groups of group.* with aliased names "alias-group.*"<BR>
<KBD>
MOUNT="alias-group. nntp://<I>server1</I>/<I>group</I>."
</KBD>
</UL>

<P>
Example: POP server to NNTP client<UL>
// mounts a mail spool as if it is a newsgroup named "+pop.user.host".<BR>
<KBD>
# delegated -P119 SERVER=nntp
  MOUNT="= pop://<I>user</I>:<I>pass</I>@<I>host</I>/"
</KBD>
</UL>

<P>
Example: NNTP server to HTTP client<UL>
<KBD>
# delegated -P80 MOUNT="/news/* nntp://<I>nntpServer</I>/*"
</KBD>
<!--
<P>
<KBD>MHGWCONF="hide:From:!@delegate,!@etl"</KBD>
-->
</UL>

<A NAME=origin_NNTP TITLE="origin NNTP server">
<P>
Example: origin NNTP-DeleGate<UL>
<KBD>
# delegated -P119 SERVER=nntp://-.-/
</KBD>
<P>
Specifying "-.-" as the destination server in SERVER parameter of
NNTP-DeleGate means using the DeleGate as an origin NNTP server
which has its own spools to be retrieved and posted.
To make a new newsgroup named <I>newsGroup</I>,
make an empty file<UL>
<KBD>
'${ETCDIR}/news/groups/<I>newsGroup</I>'</UL>
</KBD>
To relay an existing "/path/of/MH-folder" as <I>newsGroup</I>,
make a file like above and fill it with content like
<UL>
<KBD>0 0 0 0 /path/of/MH-folder</KBD><BR>
(four zeros followed by a path name of a MH-folder)
</UL>
<P>
When a posted article has Unix-From like "From <I>user</I> <I>date</I>"
as the first line or has a "Unix-From: <I>user</I> <I>date</I>" header,
the article number for the article is set to the one indicated in
"X-Seqno" (or "X-Sequence") header if exists,
and the creation date of the spool file will be set to the <I>date</I>
in the Unix-From.
</UL>
</A>

<A NAME=anon_NNTP TITLE="anonymizing NNTP articles">
<P>
<B>Anonymizing NNTP articles</B>
<P>
To disable mail address mining for spamming, mail addresses transferred
over NNTP protocol can be anonymized with the "rewaddr" MountOption as this:
<P>
<UL>
<KBD>MOUNT="* nntp://<I>server</I>/* rewaddr=*:%l@%r"</KBD>
</UL>
</P>
This "rewaddr" MountOption can be used in MOUNT parameter both for NNTP
and HTTP DeleGate.
To suppress the rewriting of mail addresses for specific addresses or domains,
specify "nomapemail" option of NNTPCONF like this:
<UL>
<KBD>NNTPCONF="nomapemail:{etl.go.jp,feedback@delegate.org,services@}"</KBD>
<BR>
</UL>

Anonymization can be controlled by the poster of each article via
a NNTP/HTTP gateway DeleGate.  For example, a DeleGate server for NNTP/HTTP
gateway can be configured like this:
<UL><KBD>
SERVER=http -P8080 MOUNT="/ml/* nntp://<I>server</I>/mail-lists.*" ...<BR>
</KBD></UL>
The anonymization of each article, or articles posted by a poster, is
controlled in the page at:<BR>
<UL><KBD>
<KBD>http://<I>DeleGate</I>:8080/ml/<I>groupName</I>/<I>articleNumber</I>?Admin</KBD>
</KBD></UL>
An authentication key for each poster is required to control anonymization.
The key can be sent automatically via mail, or got with "-Fauthkey" command:
<UL><KBD>
delegated -Fauthkey foo@bar.dom
</KBD></UL>
Each key is encrypted with a passphrase, of which default value is an empty
string.  It should be changed to a non-default value with the AUTH=pass
parameter for each DeleGate server or -Fauthkey command:
<UL><KBD>
delegated AUTH="pass:admin:creysalt:<I>PassPhrase</I>" SERVER=nntp ...<BR>
delegated AUTH="pass:admin:creysalt:<I>PassPhrase</I>" SERVER=http ...<BR>
delegated AUTH="pass:admin:creysalt:<I>PassPhrase</I>" -Fauthkey ...<BR>
</KBD></UL>
This anonymization can be applied as an off-line filter command too:
<UL><KBD>
delegated MIMECONV="rewaddr:*:%l@%r" -FdeMime &lt; infile &gt; outfile
</KBD></UL>
If necessary,
<KBD>MIMECONV="nomapemail:{<I>listOfAddress</I>}"</KBD> and
<KBD>AUTH=pass:admin:...</KBD> can be used with -FdeMime.
</UL>
</A>

</A>
</UL>

<A NAME="NNTP_mount" TITLE="MountOptions for NNTP">
<PRE>
MountOptions for NNTP
</PRE>
<UL>
<DL>
<DT>hide={<I>GroupList</I>}
<DD>List of patterns of news group names to be
hidden to clients.<BR>
Example: "hide={alt.*,!alt.comp*}"

<DT>cache=no
<DD>disable any caching.

<DT>cache=no-article
<DD>disable ARTICLE caching.

<DT>cache=no-list
<DD>disable LIST caching.

<DT>upact:<I>Invoke</I>/<I>Reload</I>/<I>Posted</I>
<DD>control updating of LIST (active list) cache.
The same meaning with
NNTPCONF=upact:<I>Invoke</I>/<I>Reload</I>/<I>Posted</I>
except this controls only the destination server of this MOUNT parameter.

<DT>rewaddr={<I>headerList</I>}:<I>addrFormat</I>
<DD>
Rewrite E-mail address appeared in header fields or the body of a message.
For example, "rewaddr={From,Body}:%l@%r" will rewrite an address
"foo@host.bar.org" to "foo@bar" in the "From" header field and in the body.

</DL>
</UL>
</A>

<A NAME=NNTPCONF TITLE="">
<PRE>
NNTPCONF parameter* ==  NNTPCONF=<I>what</I>:<I>conf</I>
                    --  default: NNTPCONF=upact:600/300/120
</PRE>
<UL>
<DL>
<DT>pathhost:<I>Server</I>/<I>PathHost</I>
<DD>define a logical <I>PathHost</I> name
of the physical <I>Server</I>-host.<BR>
Example: <KBD>NNTPCONF="wall.etl.go.jp/delegate.org"</KBD>

<DT>upact:<I>Invoke</I>/<I>Reload</I>/<I>Posted</I>
<DD>control updating of active list cache.
<I>Invoke</I> and <I>Reload</I> specifies expire time of the cache in seconds.
After an article is posted via the DeleGate, the cache will be
updated whenever the client checked it (by LIST command),
within the period specified by <I>Posted</I>.

<DT>overview.fmt:{<I>FieldList</I>}
<DD>default -- overview.fmt:{Subject,From,Data,Message-ID,References,Bytes,Lines}<BR>
The format of the XOVER response generated by the DeleGate.

<DT>xover:<I>Number</I>
<DD>default -- xover:2000<BR>
Limit the maximum number of articles in "XOVER <I>range</I>"

<DT>nice:<I>Number</I>
<DD>Set the nice value if defined.

<DT>ondemand
<DD>postpone the connection establishment to a server until 
something from the server become necessary

<DT>dispensable
<DD>continue the client session even if a server is disconnected

<DT>auth:{<I>srcHostList</I>}
<DD>Force authentication (using AUTHINFO command) at the beginning of the NNTP
session, if the client hosts is included in the <I>srcHostList</I>.
This parameter should be set if the NNTP server does any
authentication for any subset of users, and this DeleGate does
caching for NNTP.

<DT>authcom:{<I>commandList</I>}
<DD>Define a set of NNTP commands which need authentication before used.

<DT>server:<I>host</I>[:<I>port</I>][/<I>grouplist</I>]
<DD>set NNTP server(s) for HTTP requests by URLs nntp://*/... or news:...

<DT>nntpcc:<I>Number</I>
<DD>default -- nntpcc:1<BR>
Specify "nntpcc:0" to disable "connection cache" for NNTP.
</DL>
</UL>
</A>
</A>


<A NAME=serv_LDAP TITLE="LDAP proxy">
<P>
<B>LDAP proxy</B>
<UL>
<P>
Example: proxy LDAP-DeleGate<UL>
<KBD>
# delegated -P389 SERVER=ldap
</KBD>
<P>
Specify this DeleGate server as your client's LDAP server and
append "@host.of.ldap-server" after root directory name (i.e.
name of baseObject for search).
<P>
<KBD>
% ldapsearch -x -h localhost -p 389 -b o=netcenter.com@memberdir.netscape.com
</KBD>
</UL>
<P>
<A NAME=LDAP_MOUNT>
Example: LDAP gateway<UL>
<KBD>
<DL>
<DT>
# delegated -P389 SERVER=ldap \
<DD>      MOUNT="o=xxx* ldap://aaa.domain nocase" \
<DD>      MOUNT="o=yyy* ldap://bbb.domain nocase"
</DL>
<P>
Search requests on base directory named "o=xxx..." sent to this LDAP-DeleGate
is forwarded to the LDAP-server "ldap://aaa.domain".
</KBD>
</UL>
</A>

</UL>
</A>

<A NAME=serv_Whois TITLE="Whois proxy">
<P>
<B>Whois proxy</B>
<UL>
Example: proxy Whois-DeleGate<UL>
<KBD>
<I>firewall</I># delegated -P43 SERVER=whois<BR>
<I>internal</I>% whois -h <I>firewall</I> "whois://whois.nic.ad.jp/help"<BR>
</KBD>
</UL>
</UL>
</A>


<A NAME=serv_X TITLE="X proxy">
<P>
<B>X proxy</B>
<UL>
Example: relaying to a display on a single host
<UL>
<KBD>
<I>x-server</I>% xhost <I>firewall</I><BR>
<I>firewall</I>% delegated -P6008 SERVER=X://<I>x-server</I><BR>
<I>internal</I>% xterm -display <I>firewall</I>:8
</KBD>
</UL>
<P>
Example: relaying to two displays on a single server host
<UL>
<KBD>
<I>firewall</I>% delegated -P6002-6003 SERVER=X://<I>x-server:-6002</I><BR>
</KBD>
</UL>
<P>
Example: relaying to two server hosts
<UL>
<KBD>
<DL>
<DT><I>firewall</I>% delegated -P6011-6012 \<BR>
<DD>SERVER=X://x-server1:-:{*:6011} \<BR>
SERVER=X://x-server2:-:{*:6012}<BR>
</DL>
</KBD>
</UL>
</UL>
</A>


<A NAME=serv_Gopher TITLE="Gopher proxy">
<P>
<B>Gopher proxy</B>
<P>
<UL>
Example: Gopher-DeleGate<UL>
<KBD>
<I>firewall</I>% delegated -P8070 SERVER=gopher://gopher.ncc.go.jp
<P>
<I>internal</I>% gopher <I>firewall</I> 8070<BR>
<I>internal</I>% gopher -p -_-gopher://gopher.tc.umn.edu <I>firewall</I> 8070
</KBD>
</UL>
</UL>
</A>


<A NAME=serv_SSL TITLE="SSL proxy">
<P>
<B>SSL proxy</B>
<P>
<UL>
Using a filter program "<I>sslway</I>" in FCL, FSV, or
<A HREF="#cond-filter">CMAP</A> parameter,
client-side and/or server-side communication can be wrapped with
SSL protocol.
To use this filter, you need sslway and relevant PEM files placed
at some directories in LIBPATH, typically at DGROOT/lib.
See
<A HREF="http://www.delegate.org/delegate/ssl/">http://www.delegate.org/delegate/ssl/</A>
for more details.
( Sslway as an external command has become unnecessary.
Recent versions of DeleGate uses the built-in sslway when
it can utilize dynamic libraries of SSL.  See
<A HREF="http://www.delegate.org/delegate/tls/">http://www.delegate.org/delegate/tls/</A>
)
<P>
Example: relay between non-SSL client and SSL server<UL>
<KBD>
# delegated -P80 SERVER=http FSV=sslway MOUNT="/* https://server/*"</UL>
</KBD>
Example: relay between SSL client and non-SSL server<UL>
<KBD>
# delegated -P443 SERVER=https FCL=sslway MOUNT="/* http://server/*"</UL>
</KBD>
</UL>
</A>

<A NAME=serv_DNS TITLE="DNS proxy/server">
<P>
<B>DNS (Domain Name System) proxy/server</B>
<P>
<UL>
A DNS-DeleGate server relays host name data gathered
from multiple sources including DNS, NIS and local file.
It can provide limited type of resource records only;
A, PTR, SOA and simplified MX.
SOA record is composed with information of
<A HREF="#DNSCONF">DNSCONF</A> configuration.
<P>
Example: {NIS,FILE,DNS}/DNS gateway<UL>
<KBD>
<DL>
<DT># delegated -P53 SERVER=dns \<BR>
<DD>RESOLV=cache,file,nis DNSCONF=domain:my.domain
</DL>
</KBD>
</UL>
<P>
MX record for <I>hostname</I> is generated from
-MX.<I>hostname</I> if it is given (like the example below),
or the A record for <I>hostname</I> is used.
Priorities among multiple MX records can not be represented
in the current implementation.
<P>
Example: <I>hosts</I> table to use hostA as the MX of hostB<UL>
<KBD>
10.1.2.3 hostA<BR>
10.4.5.6 hostB, -MX.hostA
</KBD>
</UL>
</UL>
</A>

<A NAME=DNSCONF TITLE="">
<PRE>
DNSCONF parameter*  ==  DNSCONF=<I>what</I>:<I>value</I>
</PRE>
<UL>
Specify the configuration of the DNS-DeleGate server.
<P>
<TABLE BORDER=0 CELLSPACING=0>
<TR><TD>para:<I>N</I><TD> -- the number of parallel server process [2]
<TR><TD>domain:<I>FQDN</I><TD> -- [domain name of the host of DeleGate]
<TR><TD>origin:<I>FQDH</I><TD> -- [host name of the host of DeleGate]
<TR><TD>admin:<I>Email</I><TD> -- the mail address of the administrator [ADMIN]
<TR><TD>mx:<I>FQDH</I><TD> -- [primary host name of -MX.<I>host</I> if exists or inquired <I>host</I> itself]
<TR><TD>serial:<I>N</I><TD> -- serial number
[%Y%m%d%h of the last configuration change]
<TR><TD>refresh:<I>period</I><TD> -- refresh interval [6h]
<TR><TD>retry:<I>period</I><TD> -- retry interval [10m]
<TR><TD>expire:<I>period</I><TD> -- expire period [14d]
<TR><TD>minttl:<I>period</I><TD> -- minimum ttl [6h]
</TABLE>
</UL>
</A>


<A NAME=serv_CU-SeeMe TITLE="CU-SeeMe proxy">
<P>
<B>CU-SeeMe proxy</B>
<UL>
Example: proxy CU-SeeMe-DeleGate
<UL>
<KBD>
<I>firewall</I>% delegated -P7648 SERVER=cuseeme://Reflector/<BR>
<I>INTERNAL</I># delegated -P7648 SERVER=cuseeme://<I>firewall</I>/<BR>
<I>internal</I>% {use <I>firewall</I> or <I>INTERNAL</I> as a proxy-reflector for Reflector}<BR>
</KBD>
</UL>
</UL>
</A>
</A><!-- end of ProtoSpec -->


<A NAME=RESERVED TITLE="Reserved Names">
<P>
<B>RESERVED NAMES</B>
<UL>
Special names "-"and "-.-", when it is used in the "<I>host</I>:<I>port</I>" part
of URL,  means the host and port of the DeleGate itself.  And URL
"http://-.-/-/" is reserved for a entry point of a control page of
DeleGate.

</UL>
</A>

<A NAME=AF_LOCAL TITLE="AF_LOCAL Sockets">
<P>
<B>AF_LOCAL SOCKETS</B>
<UL>
Sockets in AF_LOCAL (or AF_UNIX) address space can be referred like
host names in pseudo top-level domain ".af-local".
For example, a socket with address "/tmp/sock" can be referred as
"sock.tmp.af-local", then it is referred in command line options like
"-Psock.tmp.af-local", SERVER=http://sock.tmp.af-local:123", or so.
Port number of socket is ignored in this naming.
</UL>
</A>

<P>
<A NAME=customize TITLE="Customization">
<B>CUSTOMIZATION</B>
<UL>
The source of built-in data of DeleGate including icons and messages
are at the source code directory "src/builtin/*".
They are compiled into the executable file of DeleGate and
are accessible as resources on a run-time DeleGate with
URL "http://<I>delegate</I>/-/builtin/*".
Those data can be replaced without recompiling DeleGate but
by defining MOUNT for them.
For example, the error message returned on forbidden access is at
"http://<I>delegate</I>/-/builtin/mssgs/403-forbidden.dhtml", and
it can be replaced by a MOUNT parameter like this:
<P>
<UL>
MOUNT="/-/builtin/mssgs/403-forbidden.dhtml /tmp/forbidden.dhtml"
</UL>
<P>
In this example, the MOUNT replaces only the forbidden message
and the alternative data is a local file under "/tmp".
But in general, a group of builtin-data can be replaced
using wild-card (*) notation and
alternative data can be placed at remote host which can be accessible
via HTTP or FTP.  For example, copy the whole of "src/builtin/"
into "http://yourwww/delegate/builtin/" and MOUNT it like this:
<P>
<UL>
MOUNT="/-/builtin/* http://yourwww/delegate/builtin/*"
</UL>
<P>
Loading remote data will not suffer from overhead
as long as cache is enabled,
since MOUNTed built-in data are cached and reused like usual data. 
</UL>
</A>


<A NAME=defense TITLE="Defense Against Attackers">
<P>
<B>DEFENSE AGAINST ATTACKERS</B>
<UL>
Immediately after an occurrence of fatal signal, like SIGSEGV or SIGBUS,
DeleGate stops serving to the client host which caused the fatal error,
since the error could be a sign of a failed trial of intrusion.
At the same time, to notify the incident, DeleGate will send a
report mail to the administrator named in the ADMIN parameter.
<P>
Since the most typical method of attackers is buffer overflow on stack,
expecting a target buffer resides at a certain address,
randomizing stack address will be effective to decrease the probability
of successful attack.
And a failure of attack will cause a fatal error
to be caught by DeleGate.
<P>
A suspicious client host will be shut out until a relevant file
(under ADMDIR/shutout/) is removed,
or the file is expired by TIMEOUT=shutout (30 minutes by default).
For safety, TIMEOUT="shutout:0" (never timeout) is desirable
not to give a second chance to the attacker.
But as fatal errors are highly provably caused by usual bugs in DeleGate itself,
it may be troublesome to be the default value...

<P>
Anyway you should be aware of following options if you are aware of
preventing this kind of attacks,
as well as <A HREF="#acl">access control</A> configurations.
<P>
<UL>
<DL>
<DT><KBD>TIMEOUT=shutout:<I>N</I></KBD> [30m] ... shortest attack retrial interval
<DT><KBD>MAXIMA=randstack:<I>N</I></KBD> [32] ... randomize stack address
<DT><KBD>MAXIMA=randenv:<I>N</I></KBD> [1024] ... randomize environment variable
<DT><KBD>MAXIMA=randfd:<I>N</I></KBD> [32] ... randomize client's socket descriptor
<DT><KBD>CHROOT=<I>dirPath</I></KBD> ... restrict accessible file space
<DT><KBD>OWNER=<I>user</I></KBD> [nobody] ... restrict the ability of the DeleGate process
<DT><KBD>ADMIN=<I>E-mail-address</I></KBD> ... must be correct and SMTP-deliverable
<DT><KBD>DGSIGN=<I>mask</I></KBD> [V.R.P/Y.M.D] ... hide DeleGate version to client and server
<DT><KBD>-P<I>host:</I>port</KBD> [0.0.0.0:] ... restrict the interface of an entrance port
<DT><KBD>-Tx</KBD> [off] ... disable execve() system call
<DT><KBD>-Fimp</KBD> [none] ... restrict users and capability of DeleGate executable
<DD>
</DL>
</UL>

<P>
At the start up time, the original environment variables and 
command line arguments on stack area are moved to heap area and cleared
not to be utilized for intrusion code by attackers.
At the same time, a dummy environment variable named <I>RANDENV</I>
with a value of random length (with maximum MAXIMA=randenv)
is inserted to randomize addresses of environment variables
to be inherited to child processes like filter programs and CGI programs.
</UL>
</A>

<A NAME=EncryptedConf TITLE="Encrypted Configuration">
<P>
<B>ENCRYPTED CONFIGURATION</B>
<UL>
Configuration data can be in encrypted format which requires a passphrase
to decrypt it.  Such a passphrase is specified as the password
for a special user, "sslway" and "config",
representing the kind of configuration.
<BR>
The passphrase to decrypt the private-key for SSL is given as
the password of a special user named "sslway" in a special domain, as this: 
<UL>
<KBD>delegated -Fauth -a sslway:<I>Passphrase</I> -dgauth@admin</KBD><BR>
</UL>
<P>
The <I>Passphrase</I> will be used by SSL library for decryption of the
private-key, which might be bundled in a file together with a certificate,
like this for example:
<UL>
<KBD>delegated -P443 SERVER=https STLS="fcl,sslway -cert cryptedKey.pem"</KBD>
</UL>
<P>
Another passphrase is for getting <A HREF=#CryptedParams>encrypted
configuration</A> parameters specified as "+=conf.cdh".
The passphrase to decrypt such data is given as the password of
a special user named "config" in a special domain, as this:
<UL>
<KBD>delegated -Fauth -a config:<I>Passphrase</I> -dgauth@admin</KBD><BR>
</UL>
<P>
The suffix ".cdh" means that the data is encrypted with "Credhy" algorithm.
A file can be encrypted and decrypted with -Fcredhy as follows:
<UL>
<KBD>delegated -Fcredhy <I>Passphrase</I> < conf > conf.cdh</KBD><BR>
<KBD>delegated -Fcredhy <I>Passphrase</I> -d < conf.cdh > conf</KBD><BR>
</UL>
<P>
An encrypted configuration file can be used as follows:
<UL>
<KBD>delegated +=conf.cdh</KBD><BR>
<KBD>delegated +=http://server/path/conf.cdh</KBD>
</UL>
<P>
When a configuration file is loaded from a remote server,
it is strongly recommended to use the encryption.
<BR>
As shown in the examples, those special user names to hold passphrases
are in the special domain "-dgauth@admin" [<A HREF=#dgauth>DGAuth</A>].
The storage for passwords in DGAuth are encrypted with a passphrase,
or <I>MasterKey</I>.
It can be specified as this:
<UL>
<KBD>CRYPT=pass:<I>MasterKey</I></KBD>
</UL>
<P>
If the <I>MasterKey</I> is not specified with a CRYPT parameter
for a DeleGate which requires it,
then it will be asked interactively.
When restarting DeleGate with "-r" or SIGHUP,
or restarting in short time after termination,
or possibly after rebooting the host machine,
the <I>MasterKey</I> is automatically saved and reused
without the interaction.
</UL>
</A>


<A NAME=Platforms TITLE="Platform Specific Issue">
<B>PLATFORM SPECIFIC ISSUE</B>
<UL>
<DL>

<A NAME=Unix>
<P>
<DT>Unix
<DD>
 <DL>
 <A NAME="inetd" TITLE="Invocation from Inetd">
 <DT>Invocation from Inetd
 <DD>
 Both "nowait" and "wait" status can be specified in inetd.conf.
 In "nowait" status, the DeleGate will processes just one request
 (session) and exits, thus is ineffective.
 In "wait" status, the DeleGate will process multiple requests;
 maximum count of request may be limited to <I>N</I> by
 "<KBD>MAXIMA=service:<I>N</I></KBD>".
 </DD>
 </A>
 <P>
 <A NAME="subin" TITLE="external privileged commands">
 <DT>Privileged operations without being superuser
 <DD>
Some operations of DeleGate needs the privilege of super-user, but
running whole DeleGate process under super-user's ability is not
desirable for security.  To solve the problem, you can execute DeleGate
by normal user while executing a privileged operation by a small external
program with "set user ID on execution" flag.
Those external subsidiary programs are placed at DGROOT/subin/ by
optional installation.
 <P>
  <UL>
  <DL>
  <DT>dgpam -- to do PAM authentication (<A HREF=#AUTHORIZER>AUTHORIZER</A>)
  <DT>dgchroot -- to do chroot(2) (<A HREF=#CHROOT>CHROOT</A>)
  <DT>dgbind -- to do bind(2) to privileged ports
     (<A HREF=#opt_P>-P</A>,
      <A HREF=#SRCIF>SRCIF</A>,
      <A HREF=#serv_FTP>FTP</A> data,
      <A HREF=#serv_Socks>SOCKS</A> server)
  </DL>
  </UL>
 </DD>
 </A>
 </DL>
 </DD>
</A>

<A NAME=MSWin TITLE="MS Windows">
<P>
<DT>Windows
<DD>
 <DL>
 <DT>Starting as a service
 <DD>
 On WindowsNT/2000, DeleGate automatically starts to run as a service
 (as a background process) by default,
 when invoked from the command prompt without -v or -f option.
 To stop and/or remove a DeleGate running as a service with
 -P<I>xxxx</I> option, enter "delegated -P<I>xxxx</I>"
 at the command prompt and answer to the simple query from the DeleGate.
 On Windows95/98, DeleGate runs as a foreground process only.
 </DL>
</DD>
</A>

<P>
<DT>CYGWIN
<DD>Seems to have to be invoked by the Administrator.

<A NAME=OS2 TITLE="OS/2">
<P>
<DT>OS/2
<DD>The optional loopback device (localhost) is necessary
to be installed.
</DD>
</A>

</DL>
</UL>
</A><!-- end of Platforms -->

<A NAME=RESTART TITLE="Restarting">
<P>
<B>GENTLE RESTART</B>
<UL>
To make DeleGate restart gently
without aborting ongoing sessions in child processes,
and without changing the process ID of the DeleGate
and holding its resources like entrance ports,
send SIGHUP signal to the DeleGate process.
This can be done in a platform independent way
using <A HREF="#func_kill">-Fkill</A> function like this:
<P>
<UL>
<KBD>delegated -Fkill-hup -P<I>port</I></KBD>
</UL>
<P>
Also restarting with SIGHUP can be done by remote HTTP clients
at "http://<I>delegate</I>/-/admin/"
using <A HREF="#AUTH_admin">AUTH=admin</A> parameter.
<P>
Restarting will be done after a configuration of DeleGate is changed. 
Parameters to be reloaded on restart must be given with
<A HREF="#Substitution">+=<I>parameters</I></A> notation
for parameter substitution.
Other options (parameters) given as command line arguments will be
inherited as is to the restarted DeleGate process.
<P>
Another purpose of restarting can be cleaning up
of possible garbage or leaked resources
like heap memory and file descriptors.
For this purpose,
DeleGate can be restarted periodically by
<A HREF="#TIMEOUT"><KBD>TIMEOUT=restart</KBD></A> or
at each scheduled time by
<A HREF="#act_restart">-restart</A> action in CRON parameter.
</UL>
</A>

<A NAME=Functions>
<B>FUNCTIONS</B>
<UL>
<P>
Given a <A HREF="#opt_Func">-F<I>function</I></A> option,
DeleGate runs to do the specified function
which typically is a client-side action of a certain protocol.
You can omit entering lengthy "delegated -F" by
giving a file name "<I>function</I>" to an DeleGate executable file
and just call it as <I>function</I>.
The matching of <I>function</I> name is case-insensitive.
<P> 
Command line options before -F<I>function</I> and after "--" option
is regarded as options for DeleGate rather than for the <I>function</I>,
as delegated <I>dgopt</I> ... <I>dgopt</I>
-F<I>func</I> <I>fopt</I> ... <I>fopt</I>
-- <I>dgopt</I> ... <I>dgopt</I>.
As an exception, parameter option, in <I>name</I>=<I>value</I> format,
is recognized as a parameter for DeleGate even if it appeared at
<I>fopt</I> position.
<P> 
Example: using DeleGate as a resolver
<UL>
<KBD>
% delegated -Fresolvy www.delegate.org<BR>
% ln -s delegated Resolvy<BR>
% Resolvy www.delegate.org
</KBD>
</UL>
<P>
The following is a list of major functions.
<P>
<DL>
<DT><KBD>-Fhelp</KBD>
<DD>put a list of available functions
<A NAME=func_kill TITLE="-Fkill function">
<DT><KBD>-Fkill[-hup] -P<I>port</I></KBD>
<DD>terminate (or restart) the DeleGate sending SIGTERM (or SIGHUP)
</DD>
</A>
<DT><KBD>-Fimp</KBD>
<DD>implant configuration parameters into the executable file
<DT><KBD>-Fcgi [<I>DeleGateOptions</I>]</KBD>
<DD>run as a CGI program of an arbitrary <A HREF="#Fcgi">HTTP</A> server
<DT><KBD>-Fconnect <I>host</I> <I>port</I>[/udp] [XCOM=<I>clientCommand</I>]</KBD>
<DD>like a telnet client, connect to the specified <I>host</I>:<I>port</I>
    and relay the standard I/O to/from it.
<DT><KBD>-Fresolvy {[-MX.]<I>hostname</I> | <I>IPaddress</I>[-<I>num</I>]}</KBD>
<DD>like nslookup(8), resolve a given host name or IP address
    (can be a range as 10.10.10.1-128)
<DT><KBD>-Ffindu</KBD> [-atime <I>N</I>] [-ls] [-du] [-rm] ... [<I>dir</I>]*
<DD>like find(1), find a file to apply a specified action.
    Usage will be shown by "delegated -Ffindu".<BR>
Example: doing "find . -ls" together with "du(1)"<UL>
    <KBD>delegated -Ffindu -ls -du</KBD></UL>
<DT><KBD>-Fdget [-h] [-o] [-e<I>encoding</I>] [PROXY=<I>host</I>:<I>port</I>]
    [<A HREF="#MYAUTH">MYAUTH</A>=<I>user</I>:<I>pass</I>] <I>URL</I></KBD>
<DD>download a resource specified by <I>URL</I>,
and put to standard output with "-o" option.
With "-h" option, the header part of a HTTP response message will be put
together.

<!--
<A NAME=func_SockMux TITLE="-Fsockmux function"><P>
<DT><KBD>-Fsockmux [-vd] {-A<I>port</I> | -C<I>port</I> | -I<I>fifo</I> -O<I>fifo</I> | -X<I>fifo</I>} [-Q<I>port</I>]
<DD>
relay <A HREF="#serv_SockMux">SockMux</A> protocol by a foreground function
rather than a server.
The communication channel between SockMux-DeleGate can be established as
a TCP/IP connection, accepting with -A<I>host:port</I> and connecting with
-C<I>host:port</I>.
Or the channel can be established via a certain communication device act as FIFO
like named PIPE,
using it for input and output by -I<I>fifo</I> and -O<I>fifo</I> or
using it both for input and output by -X<I>fifo</I>.
PORT=<I>port</I> specifies the entrance of the tunnel with the exit at peer host,
-Q<I>port</I> specifies the exit of the tunnel with the entrance at peer host.
The tunnel can be single-directional by omitting -P at a side and omit -L
at another side.
<BR>
Example:<UL>
// channel is established as a TCP/IP connection at hostX:8000<BR>
// hostX:8023 is forwarded to hostY:23<BR>
// hostY:8023 is forwarded to hostX:23<BR>
hostX% delegated -PhostX:8023 -Fsockmux -AhostX:8000 -QhostX:23<BR>
hostY% delegated -PhostX:8023 -Fsockmux -ChostX:8000 -QhostY:23<BR>
</UL>
<P>
</A>
-->

<DT><KBD>-Ficp</KBD> [-h <I>server</I>] <I>URL</I>
<DD>work as an ICP client.
    Usage will be shown by "delegated -Ficp".
<DT><KBD>-Fsched {"<A HREF="#CRON"><I>crontabSpec</I></A>" | <I>crontabFile</I> | <I>schedSpec</I>}*</KBD>
<DD>
like cron(8), cause specified actions at specified timing.<BR>
Example: cause an action every 15 minutes<UL>
<KBD>
delegated -Fsched "0,15,30,45 * * * * /bin/date"
</KBD>
</UL>
<I>schedSpec</I> is the canonical format of scheduling specification.
<UL>
<I>schedSpec</I> == <I>Wday</I>:<I>year</I>:<I>month</I>:<I>mday</I>:<I>Hour</I>:<I>Min</I>:<I>Sec</I>:<I>action</I>
</UL>
Example: cause an action every 15 seconds<UL>
<KBD>
delegated -Fsched "*:*:*:*:*:*:0,15,30,45:/bin/date"
</KBD>
</UL>

<DT><KBD>-Fmd5 [<I>infile</I>]</KBD>
<DD>output the MD5 digest of input data

<A NAME=func_auth TITLE="-Fauth function">
<DT><KBD>-Fauth -{a|d|v} <I>username</I>[:<I>password</I>] <I>hostname</I>[:<I>portnumber</I>] [<I>expire</I>]</KBD>
<DD>Add, delete or view predefined (or cached) authorization information
for <I>hostname</I> as a server for <A HREF="#AUTHORIZER">AUTHORIZER</A>.
If <I>hostname</I> is prefixed with "-", it is regarded as a virtual name
without a real server.
<BR>
Example:<UL>
<KBD>
delegated -Fauth -a ken:blahblah -smtp.users.local<BR>
</KBD>
// and refer this as AUTHORIZER=-smtp.users.local
</U>
</DD>
</A>

</DL>
</UL>
</A><!-- end of Functions -->

<A NAME=FILES>
<P>
<B>FILES</B>
<UL>
<TABLE BORDER=0 CELLSPACING=0>
<TR><TD><KBD>${DGROOT}/etc</KBD>  <TD> -- persistent files mainly for configuration<BR>
<TR><TD><KBD>${DGROOT}/lib</KBD>  <TD> -- library files and scripts<BR>
<TR><TD><KBD>${DGROOT}/adm</KBD>  <TD> -- important log relevant to administration<BR>
<TR><TD><KBD>${DGROOT}/log</KBD>  <TD> -- log files which will grow up<BR>
<TR><TD><KBD>${DGROOT}/work</KBD> <TD> -- for core dump<BR>
<TR><TD><KBD>${DGROOT}/cache</KBD><TD> -- for cached data<BR>
<TR><TD><KBD>${DGROOT}/act</KBD>  <TD> -- control info. of currently active DeleGate processes<BR>
<TR><TD><KBD>${DGROOT}/tmp</KBD>  <TD> -- volatile files which should be erased on shutdown<BR>
</TABLE>
<P>
See the description of <A HREF="#DGROOT">DGROOT</A> parameter
and <A HREF="#localfile">Local file usage</A>
for more information.
</UL>
</A>

<A NAME=Acronyms>
<B>Acronyms</B>
<UL>
<DL>
<DT><A NAME=AIST>AIST -- National Institute of Advanced Industrial Science and Technology</A>
<DT><A NAME=CERN>CERN -- European Organization for Nuclear Research</A>
<DT><A NAME=ETL>ETL -- ElectroTechnical Laboratory (was integrated to AIST)</A>
<DT><A NAME=MITI>MITI -- Ministry of International Trade and Industry (antecedents of METI)</A>
<DT><A NAME=METI>METI -- Ministry of Economy, Trade and Industry</A>
<DT><A NAME=NCSA>NCSA -- National Center for Super-computing Applications</A>
</DL>

<DL>
<DT><A NAME=BSD>BSD -- Berkeley Software Distribution (BSD UNIX)</A>
<DT><A NAME=CYGWIN>CYGWIN -- A system provides UNIX utilities on MS-Windows</A>
<DT><A NAME=OSX>OSX -- Mac OSX (Apple version of UNIX)</A>
<DT><A NAME=UNIX>UNIX -- Uniplexed Information and Computing Service: Linux, BSD, Mac OSX, Solaris, and other</A>
</DL>

<DL>
<DT><A NAME=CFI>CFI -- Common Filter Interface of DeleGate</A>
<DT><A NAME=CGI>CGI -- Common Gateway Interface</A>
<DT><A NAME=CSS>CSS -- Cascading Style Sheets</A>
<DT><A NAME=DHCP>DHCP -- Dynamic Host Configuration Protocol</A>
<DT><A NAME=DNS>DNS -- Domain Name System/Service</A>
<DT><A NAME=FTP>FTP -- File Transfer Protocol</A>
<DT><A NAME=FWTK>FWTK -- FireWall Tool Kit</A>
<DT><A NAME=HTML>HTML -- Hyper Text Markup Language</A>
<DT><A NAME=HTTP>HTTP -- Hyper Text Transfer Protocol</A>
<DT><A NAME=HTTPS>HTTPS -- HTTP protocol over SSL (or TLS)</A>
<DT><A NAME=IMAP>IMAP -- Internet Message Access Protocol</A>
<DT><A NAME=LDAP>LDAP -- Lightweight Directory Access Protocol</A>
<DT><A NAME=LPR>LPR -- Line Printer Daemon Protocol</A>
<DT><A NAME=MIME>MIME -- Multi purpose Internet Mail Extension (Internet mail format)</A>
<DT><A NAME=MITM>MITM -- Man In the Middle (attack)</A>
<DT><A NAME=NAT>NAT -- Network Address Translation</A>
<DT><A NAME=NFS>NFS -- Network File System</A>
<DT><A NAME=NIS>NIS -- Network Information Service</A>
<DT><A NAME=NTLM>NTLM -- Net Lan Manager (what?)</A>
<DT><A NAME=NNTP>NNTP -- Network News Transfer Protocol</A>
<DT><A NAME=PAM>PAM -- Pluggable Authentication Modules</A>
<DT><A NAME=PEM>PEM -- Privacy-enhanced Electronic Mail</A>
<DT><A NAME=POP>POP -- Post Office Protocol</A>
<DT><A NAME=SPAM>SPAM -- unsolicited or undesired electronic messages</A>
<DT><A NAME=SMTP>SMTP -- Simple Mail Transfer Protocol</A>
<DT><A NAME=SSL>SSL -- Secure Socket Layer (original version of TLS)</A>
<DT><A NAME=SSH>SSH -- Secure Shell</A>
<DT><A NAME=SSI>SSI -- Server Side Inclusion</A>
<DT><A NAME=TCP>TCP -- Transport Control Protocol</A>
<DT><A NAME=TLS>TLS -- Transport Layer Security (successor version of SSL)</A>
<DT><A NAME=UDP>UDP -- User Datagram Protocol</A>
<DT><A NAME=URI>URI -- Universal Resource Identifier</A>
<DT><A NAME=URL>URL -- Uniform Resource Locator (in URI format)</A>
<DT><A NAME=WWW>WWW -- World Wide Web</A>
<DT><A NAME=XML>XML -- Extensible Markup Language</A>
</DL>

<DL>
<DT><A NAME=ASCII>ASCII -- American Standard Code for Information Interchange</A>
<DT><A NAME=EUC>EUC -- Extended Unix Code (means EUC-JP in DeleGate)</A>
<DT><A NAME=JIS>JIS -- In DeleGate, 7bits JIS code for Japanese text (ISO-2022-JP)</A>
<DT><A NAME=UCS>UCS -- Universal multiple-octet coded Character Set</A>
<DT><A NAME=SJIS>SJIS -- Shift JIS, 8bits encoding of JIS characters (Shift_JIS)</A>
</DL>

<DL>
<DT><A NAME=APOP>APOP -- Digest authentication protocol of POP protocol</A>
<DT><A NAME=CRL>CRL -- Certificate Revocation List</A>
<DT><A NAME=FIFO>FIFO -- First In First Out (data stream)</A>
<DT><A NAME=FQDN>FQDN -- Fully Qualified Domain Name (ex. www.deleate.org)</A>
<DT><A NAME=LD_LIBRARY_PATH>LD_LIBRARY_PATH -- Path to find Dynamic Linking Library</A>
<DT><A NAME=PASV>PASV -- abbreviation of Passive Mode in FTP protocol</A>
<DT><A NAME=PID>PID -- Process ID</A>
<DT><A NAME=SNI>SNI -- Server Name Indication, (virtual) host name from SSL client</A>
<DT><A NAME=RTT>RTT -- Round Trip Time</A>
<DT><A NAME=SHTML>SHTML -- HTML file to be interpreted and translated by SSI</A>
<DT><A NAME=STARTTLS>STARTTLS -- Starting TLS on the connection of non TLS</A>
</DL>

<DL>
<DT><A NAME=SIGBUS>SIGBUS -- Signal raised on bus error (fatal)</A>
<DT><A NAME=SIGCHLD>SIGCHLD -- Signal to notify status changes in a child process</A>
<DT><A NAME=SIGHUP>SIGHUP -- Signal to restart a process</A>
<DT><A NAME=SIGINT>SIGINT -- Signal to interrupt a process, usually generated by tty with Control-C</A>
<DT><A NAME=SIGSEGV>SIGSEGV -- Signal raised on segment violation (fatal)</A>
<DT><A NAME=SIGTERM>SIGTERM -- Signal to terminate a process</A>
</DL>
</UL>
</A>

<A NAME=SeeAlso TITLE="SEE ALSO">
<B>SEE ALSO</B><P>
<UL>
du(1),
ps(1),
tee(1),
cat(1),
find(1),
chroot(2),
execve(2),
getpeername(2),
getsockname(2),
pstat(2),
ptrace(2),
setgid(2),
setuid(2),
umask(2),
scanf(3),
strftime(3),
system(3),
YP(4),
crontab(5),
hosts(5),
inetd.conf(5),
cron(8),
inetd(8),
nslookup(8),
<BR>
DNS(<A HREF="ftp://ftp.ietf.org/rfc/rfc1034.txt">RFC1034</A>),
FTP(<A HREF="ftp://ftp.ietf.org/rfc/rfc959.txt">RFC959</A>),
Gopher(<A HREF="ftp://ftp.ietf.org/rfc/rfc1436.txt">RFC1436</A>),
HTML(<A HREF="ftp://ftp.ietf.org/rfc/rfc1866.txt">RFC1866</A>),
HTTP(<A HREF="ftp://ftp.ietf.org/rfc/rfc2068.txt">RFC2068</A>),
ICP(<A HREF="ftp://ftp.ietf.org/rfc/rfc2186.txt">RFC2186</A>),
<A NAME=Ident>Ident(<A HREF="ftp://ftp.ietf.org/rfc/rfc1413.txt">RFC1413</A>)</A>,
IMAP(<A HREF="ftp://ftp.ietf.org/rfc/rfc2060.txt">RFC2060</A>),
LDAP(<A HREF="ftp://ftp.ietf.org/rfc/rfc1777.txt">RFC1777</A>),
LPR(<A HREF="ftp://ftp.ietf.org/rfc/rfc1179.txt">RFC1179</A>),
MIME(<A HREF="ftp://ftp.ietf.org/rfc/rfc2045.txt">RFC2045</A>),
NNTP(<A HREF="ftp://ftp.ietf.org/rfc/rfc977.txt">RFC977</A>),
POP(<A HREF="ftp://ftp.ietf.org/rfc/rfc1460.txt">RFC1460</A>),
Socks(<A HREF="ftp://ftp.ietf.org/rfc/rfc1928.txt">RFC1928</A>),
SMTP(<A HREF="ftp://ftp.ietf.org/rfc/rfc821.txt">RFC821</A>),
Telnet(<A HREF="ftp://ftp.ietf.org/rfc/rfc854.txt">RFC854</A>),
URI(<A HREF="ftp://ftp.ietf.org/rfc/rfc2396.txt">RFC2396</A>),
URL(<A HREF="ftp://ftp.ietf.org/rfc/rfc1738.txt">RFC1738</A>),
Wais(<A HREF="ftp://ftp.ietf.org/rfc/rfc1625.txt">RFC1625</A>),
X(<A HREF="ftp://ftp.ietf.org/rfc/rfc1013.txt">RFC1013</A>)
</UL>
</A>

<A NAME=Author>
<P>
<B>AUTHOR</B>
<UL>
<KBD><PRE><font face="courier new">
  @ @
 ( - )
_<   >_
</font></PRE></KBD>

Yutaka Sato &lt;y DOT sato AT delegate DOT org><BR>
National Institute of Advanced Industrial Science and Technology (AIST),
Tsukuba, Ibaraki 305-8568, Japan
</UL>
</A>

<A NAME=FEEDBACK>
<P>
<B>FEEDBACK</B>
<UL>
Comments about DeleGate are expected to be directed to
<A HREF="mailto:feedback@delegate.org">mailto:feedback@delegate.org</A>
to be open and shared at
<A HREF="http://www.delegate.org/feedback/">http://www.delegate.org/feedback/</A>.
</UL>
</A>

<A NAME=DISTRIBUTION>
<P>
<B>DISTRIBUTION</B>
<UL>
The latest version of DeleGate is available at the following location.
&lt;URL:<A HREF="ftp://ftp.delegate.org/pub/DeleGate/">ftp://ftp.delegate.org/pub/DeleGate/</A>&gt;
in a tar+gzip format file named "delegate*.tar.gz".
</UL>
</A>

<A NAME=_help>
<A HREF=#_menu><B>HELP</B></A>
[
<A HREF=?_help>help</A>
<A HREF=http://www.delegate.org/fsx/search?index=man&sort=url>search</A>
<A HREF=?.whole>decomp</A>
<A HREF=?.parts>parts</A>
<A HREF=?.skeleton>skeleton</A>
<A HREF=${SELF}?_frames>frame</A>
]
<UL>
<PRE><font color=#000000><DL><DT>help     ... this information
<DT>search   ... searching Manual in a search engine (FreyaSX)
<DT>decomp   ... hyperlinks is rewritten to create decomposed view of each part
<DT>parts    ... each part is annotated and hyperlinks is rewritten as in "decomp"
<DT>skeleton ... list of parts of Manual
<DT>frame    ... Manual is shown in frame
<DT>[CTX]    ... jump to the label of this part in the whole plain Manual
<DT>[ALL]    ... jump to the label of this part in the "decomp" version of Manual
</DL></font></PRE>
</UL>
</A>

<PRE>
DeleGate Version 9.9.13     Last change: October 28, 2014
--------- --------- --------- --------- --------- --------- --------- ---------
</PRE>
</DIV>
</BODY>
